bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fpending issues on LSB: [<sys/types.h> does not define size_t]


From: Paul Eggert
Subject: Re: fpending issues on LSB: [<sys/types.h> does not define size_t]
Date: Thu, 28 Sep 2006 18:01:03 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

"Nelson H. F. Beebe" <address@hidden> writes:

>       
> http://sourceforge.net/tracker/index.php?func=detail&aid=773937&group_id=1107&atid=101107

That's a bug report against the LSB spec, not against lsbcc.
As I understand it, the bug was resolved by saying that
the LSB spec defers to POSIX, and that POSIX clearly
requires <sys/types.h> to define size_t, so there's
no need to change the LSB spec.

> Given that three years have passed since that bug report, no bug
> resolution is recorded, and my LSB compilers are new and dated
> 2006-05-25, I doubt that another problem report would have any effect.

But we're not talking about any bugs in the LSB spec; we're talking
about a bug in lsbcc.

Rajesh Banginwar of Intel found this problem last year, when porting
ghostview 1.5 to LSB; see
<http://developer.osdl.org/dev/dtl/docs/PortingToLinuxWebinar-08-2005.pdf>
and search for size_t.  Again, this was a bug in lsbcc, not in
ghostview.  His workaround, as shown in
<http://lists.freestandards.org/pipermail/lsb-cvslog/2005-May/019854.html>,
was to insert "typedef int size_t;" in the relevant module, which is
clearly incorrect.  As far as I know, he didn't understand the issue,
so I'm not surprised he didn't report it as a bug in lsbcc.  I'm
afraid this doesn't inspire much confidence in the LSB process.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]