Last call for bugfixes for 1.0

Last call for bugfixes for 1.0

[Rich Felker]

I'm hoping to pack up and release 1.0 in the next few days, so please
report any issues that we might be able to fix before releasing.

Rich

Re: Last call for bugfixes for 1.0

[David Grothe]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

Rich:

I notice that the library does not have a routine for rawmemchr. I 
suppose it could just be defined as memchr(ptr, c, INT_MAX).

-- Dave

On 3/15/2014 2:52 AM, Rich Felker wrote:
> I'm hoping to pack up and release 1.0 in the next few days, so please
> report any issues that we might be able to fix before releasing.
>
> Rich


[-- Attachment #2: Type: text/html, Size: 795 bytes --]

Re: Last call for bugfixes for 1.0

[Rich Felker]

On Sat, Mar 15, 2014 at 04:29:09PM -0500, David Grothe wrote:
> Rich:
> 
> I notice that the library does not have a routine for rawmemchr. I

Unfortunately this is outside the scope of the freeze, but I think we
could add it right after the release.

> suppose it could just be defined as memchr(ptr, c, INT_MAX).

No, it definitely can't. This could easily return the wrong value
(e.g. if c first occurs past offset INT_MAX) and it also invokes UB
(since there's no guarantee memchr does not read past the first
instance of c).

Rich

Re: Last call for bugfixes for 1.0

[Thomas Kreuzer]

Hello everyone,

I noticed that I am unable to wirte my own fgetln function inside a 
static linked library, even though fgetln should only be exposed by 
GNU_SOURCE or BSD_SOURCE, or shouldn't it?

I compile with "-std=c99 and -D_XOPEN_SOURCE=700"

Everything compiles fine, but seg faults, when the function is used in a 
running program, if I rename the function, everything works as expected.

Somehow the musl function fgetln interferes with my fgetln function.

regards,
Thomas

On 15.03.2014 08:52, Rich Felker wrote:
> I'm hoping to pack up and release 1.0 in the next few days, so please
> report any issues that we might be able to fix before releasing.
>
> Rich
>

Re: Re: Last call for bugfixes for 1.0

[Rich Felker]

On Sun, Mar 16, 2014 at 04:08:14PM +0100, Thomas Kreuzer wrote:
> Hello everyone,
> 
> I noticed that I am unable to wirte my own fgetln function inside a
> static linked library, even though fgetln should only be exposed by
> GNU_SOURCE or BSD_SOURCE, or shouldn't it?
> 
> I compile with "-std=c99 and -D_XOPEN_SOURCE=700"
> 
> Everything compiles fine, but seg faults, when the function is used
> in a running program, if I rename the function, everything works as
> expected.
> 
> Somehow the musl function fgetln interferes with my fgetln function.

Have you done analysis to determine that this has anything to do with
musl's fgetln function? Short of that, I suspect it's just an ordinary
crash in your fgetln. There's no reason they should be interfering;
for static linking, if fgetln is already defined then musl's fgetln.o
won't even get linked, and for dynamic linking, your symbol overrides
and nothing else accesses musl's fgetln symbol.

Rich

Re: Last call for bugfixes for 1.0

[Thomas Kreuzer]

On 16.03.2014 16:25, Rich Felker wrote:
> Have you done analysis to determine that this has anything to do with
> musl's fgetln function? Short of that, I suspect it's just an ordinary
> crash in your fgetln. There's no reason they should be interfering;
> for static linking, if fgetln is already defined then musl's fgetln.o
> won't even get linked, and for dynamic linking, your symbol overrides
> and nothing else accesses musl's fgetln symbol

As I said, if I just rename the function it works perfectly. But it 
doesn't seem to be a problem of musl either.
Sorry for making the wrong call, the problem must be somewhere else in 
my tool chain

regards

Re: Re: Last call for bugfixes for 1.0

[Rich Felker]

On Sun, Mar 16, 2014 at 07:28:05PM +0100, Thomas Kreuzer wrote:
> On 16.03.2014 16:25, Rich Felker wrote:
> >Have you done analysis to determine that this has anything to do with
> >musl's fgetln function? Short of that, I suspect it's just an ordinary
> >crash in your fgetln. There's no reason they should be interfering;
> >for static linking, if fgetln is already defined then musl's fgetln.o
> >won't even get linked, and for dynamic linking, your symbol overrides
> >and nothing else accesses musl's fgetln symbol
> 
> As I said, if I just rename the function it works perfectly. But it
> doesn't seem to be a problem of musl either.
> Sorry for making the wrong call, the problem must be somewhere else
> in my tool chain

If you can make a self-contained example to reproduce the problem, I
can take a look at it. Otherwise I don't know what I can do to help
though, and my guess is still that it's not specifically caused my
musl.

Rich

Re: Last call for bugfixes for 1.0

[orc]

15 марта 2014 г. 15:52:23 KRAT, Rich Felker <dalias@aerifal.cx> пишет:
>I'm hoping to pack up and release 1.0 in the next few days, so please
>report any issues that we might be able to fix before releasing.
>
>Rich

I probably found a small issue where ptsname() does not set errno correctly. In case of error, it always sets errno to -1.

Re: Last call for bugfixes for 1.0

[Rich Felker]

On Mon, Mar 17, 2014 at 09:34:14AM +0800, orc wrote:
> 15 марта 2014 г. 15:52:23 KRAT, Rich Felker <dalias@aerifal.cx> пишет:
> >I'm hoping to pack up and release 1.0 in the next few days, so please
> >report any issues that we might be able to fix before releasing.
> >
> >Rich
> 
> I probably found a small issue where ptsname() does not set errno
> correctly. In case of error, it always sets errno to -1.

Are you sure? It looks like something might be wrong but that's not
the behavior I gather from a quick reading of the source. It looks
more to me like errno might just be negated from its proper value.

Rich

Re: Last call for bugfixes for 1.0

[orc]

17 марта 2014 г. 9:37:34 KRAT, Rich Felker <dalias@aerifal.cx> пишет:
>On Mon, Mar 17, 2014 at 09:34:14AM +0800, orc wrote:
>> 15 марта 2014 г. 15:52:23 KRAT, Rich Felker <dalias@aerifal.cx>
>пишет:
>> >I'm hoping to pack up and release 1.0 in the next few days, so
>please
>> >report any issues that we might be able to fix before releasing.
>> >
>> >Rich
>> 
>> I probably found a small issue where ptsname() does not set errno
>> correctly. In case of error, it always sets errno to -1.
>
>Are you sure? It looks like something might be wrong but that's not
>the behavior I gather from a quick reading of the source. It looks
>more to me like errno might just be negated from its proper value.
>
>Rich

Ah, my bad, I was misguided. It returns not -1 but -9 if I pass invalid fd. Still, to interpret errno I need to make it positive number, which is not issue on glibc for example...

Re: Last call for bugfixes for 1.0

[Rich Felker]

On Mon, Mar 17, 2014 at 11:28:18AM +0800, orc wrote:
> 17 марта 2014 г. 9:37:34 KRAT, Rich Felker <dalias@aerifal.cx> пишет:
> >On Mon, Mar 17, 2014 at 09:34:14AM +0800, orc wrote:
> >> 15 марта 2014 г. 15:52:23 KRAT, Rich Felker <dalias@aerifal.cx>
> >пишет:
> >> >I'm hoping to pack up and release 1.0 in the next few days, so
> >please
> >> >report any issues that we might be able to fix before releasing.
> >> >
> >> >Rich
> >> 
> >> I probably found a small issue where ptsname() does not set errno
> >> correctly. In case of error, it always sets errno to -1.
> >
> >Are you sure? It looks like something might be wrong but that's not
> >the behavior I gather from a quick reading of the source. It looks
> >more to me like errno might just be negated from its proper value.
> >
> >Rich
> 
> Ah, my bad, I was misguided. It returns not -1 but -9 if I pass
> invalid fd. Still, to interpret errno I need to make it positive
> number, which is not issue on glibc for example...

Yes, that's what I expected from reading the source. Thanks for
confirming. I'll fix it.

Rich