[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