[Debburn-devel] [Debburn-changes] r787 - in cdrkit/trunk: genisoimage genisoimage/diag icedax include libhfs_iso librols libusal libusal/usal wodim

Harald Hoyer harald at redhat.com
Tue Feb 26 08:57:58 UTC 2008


Peter Samuelson wrote:
> [Harald Hoyer]
>>> I _really_ don't like this.  If we need to tell gcc not to warn us
>>> about lack of error handling, we should use (void) rather than making
>>> the code _look_ like we are handling errors when in reality we are not.
>> will revert.
> 
> Thanks!
> 
>>>> @@ -58,8 +58,8 @@
>>>>  #ifndef	STDERR_FILENO
>>>>  #define	STDERR_FILENO	2
>>>>  #endif
>>>> -#define	eprints(a)	(void)write(STDERR_FILENO, (a), sizeof (a)-1)
>>>> -#define	eprintl(a)	(void)write(STDERR_FILENO, (a), strlen(a))
>>>> +#define	eprints(a)	do { int ret; ret = write(STDERR_FILENO, (a), sizeof (a)-1); } while (0)
>>>> +#define	eprintl(a)	do { int ret; ret = write(STDERR_FILENO, (a), strlen(a)); } while (0)
>>> What is the purpose of this change?
>> throw away the return value. newer gcc checks ignore (void).
> 
> That surprises me.  I always thought (void) was the correct way to tell
> the compiler we intentionally do not care about a return value.
> 
>>>> +#ifdef ABC
>>>>  /*
>>>>   * Map old non extended sense to sense key.
>>>>   */
>>>> @@ -67,6 +68,7 @@
>>>>  	6, 6, 6, 5,  4,11,11,11			/* 0x28-0x2f */
>>>>  };
>>>>  #define	MAX_ADAPTEC_KEYS (sizeof (sd_adaptec_keys))
>>>> +#endif
>>> The more usual way to comment out a large block of code is "#if 0"
>> Well, look at the source:
>> $ fgrep ifdef libusal/scsierrs.c
>> #ifdef ABC
>> #ifdef  __used__
>> #ifdef  __used__
>> #ifdef  __used__
>> #ifdef  XXX
>> #ifdef  XXX
> 
> OK ... you're right, we could use a cleanup.
> 
>> New Revision: 790
> 
>> -#ifdef ABC
>> +#ifdef 0
> 
> You mean #if 0, #ifdef 0 does not work.

sure .. doh! :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3623 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.alioth.debian.org/pipermail/debburn-devel/attachments/20080226/1631c6b5/attachment.bin 


More information about the Debburn-devel mailing list