I'm inclined to say libc is not the right place to fix this. If the user
says write/send 0, what that means should be up to the io server to
decide--even if all the servers we have today are intending to implement
the same POSIX semantics.
--
To UNSUBSCRIBE, email to
You've talked a lot about detailed concrete criteria for what to include
on a release branch and how to operate it. That's a lovely discussion,
but I think it may have a bit missed the point of what I'm trying to start.
With the special exception of copyright rules, the sum of what I intended
to
The [EMAIL PROTECTED] mailing list is where the glibc ARM port's
maintenance is discussed. Please discuss ARM-related issues there.
Thanks,
Roland
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I did a couple of tests and I verified that I have no words to spare.
Adding an extra int __pad forces the structure to grow by 8 bytes
due to the long long alignment requirements.
Just reorder the fields so that the 32-bit fields are all in groups of 2 or 4.
All that should matter is that the
In the new structure we have shifted everything up because __lock is
now an integer, instead of a _pthread_fastlock with a 4 word lock
structure. Should I add padding after __lock e.g. int pad[3]?
Yes, you must dedicate those words to compatibility only.
In an old executable the following
Unfortunatly, due to alignment the NPTL pthread_cond_t grows larger
than the Linuxthreads version when I add the padding. This is the only
structure the grows larger in size than before. Is there any way I can
avoid adding the padding?
It looks to me like you have one word to spare. That's
All statically initialized locks are broken. We made locks smaller,
and changed the value of the static initialization.
Smaller? Smaller is easy. And you didn't actually reduce
__SIZEOF_PTHREAD_MUTEX_T, did you? This seems like it would not be at all
hard to accommodate just with symbol
NPTL for hppa-linux is not backwards compatible with Linuxthreads, we
have broken the pthread ABI.
Please elaborate on exactly which types and entrypoints are incompatible.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SUSv3 says this about the TZ offset:
The hour shall be between zero and 24, and the minutes (and seconds)-if
present-between zero and 59.
glibc currently clips this range at 23 hours.
I think you are correct that this is wrong as it is.
Off hand I cannot see why we clip the given
SUSv3 says this about the TZ offset:
The hour shall be between zero and 24, and the minutes (and seconds)-if
present-between zero and 59.
glibc currently clips this range at 23 hours.
I think you are correct that this is wrong as it is.
Off hand I cannot see why we clip the given
let me rephrase the problem. the following code:
#include sys/socket.h
#include sys/un.h
main ()
{
sockaddr_un test = { AF_LOCAL, };
}
This code is wrong, i.e. not portable or POSIX-compliant. You cannot use
normal initializers for a structure that
I don't know why you think there is a bug, but we don't plan to change the
sockaddr format any time soon. sa_len is not a bug.
Check that _dl_osversion (_rtld_global._dl_osversion) is getting initialized.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Check that _dl_osversion (_rtld_global._dl_osversion) is getting initialized.
I'm not sure exactly what you are asking.
What makes old static binaries crash when they try to load a new libc.so is
an old bug in the dynamic loading code when handling a reference within an
object to a hidden symbol in the same object. That was fixed by this change:
2002-09-18 Roland
I suppose what really confuses me is that the compat_symbol entries for
__ctype_* are commented out in RHL glibc, but not for __ctype32_*.
Why the asymmetry?
In the current RHL glibc sources, both are treated the same.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
I've put that fix in. I'm not quite sure what you are suggesting for a new
test, but test cases that fail on known bug regressions (i.e. one that
fails before your fix and works after it) are always welcome.
Thanks,
Roland
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
I'm not sure exactly what you are asking.
What makes old static binaries crash when they try to load a new libc.so is
an old bug in the dynamic loading code when handling a reference within an
object to a hidden symbol in the same object. That was fixed by this change:
2002-09-18 Roland
I suppose what really confuses me is that the compat_symbol entries for
__ctype_* are commented out in RHL glibc, but not for __ctype32_*.
Why the asymmetry?
In the current RHL glibc sources, both are treated the same.
I've put that fix in. I'm not quite sure what you are suggesting for a new
test, but test cases that fail on known bug regressions (i.e. one that
fails before your fix and works after it) are always welcome.
Thanks,
Roland
[/math/test-fenv.out] Error 136
That's a crash. You should look into that, but probably it is only
breaking special FP cases so it would not be the first thing to worry about.
[/math/test-float.out] Error 1
[/math/test-double.out] Error 1
[/math/test-ifloat.out] Error 1
Those might just be
[/math/test-fenv.out] Error 136
That's a crash. You should look into that, but probably it is only
breaking special FP cases so it would not be the first thing to worry about.
[/math/test-float.out] Error 1
[/math/test-double.out] Error 1
[/math/test-ifloat.out] Error 1
Those might just be
I'm not sure that it's valid C99 - my impression is that it isn't, and
the only valid way would be to have a function return the DIRENT_TYPE
by value - but it's valid GNU C and it fixes the bug I was chasing.
I'm not sure either. I don't have a copy of C99 to consult, and my
weasel-wording
I've put in a fix similar to yours but with cosmetic differences.
I believe it is valid C99.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I've put in a fix similar to yours but with cosmetic differences.
I believe it is valid C99.
The following patch bumps up the minimum kernel required for hppa,
and adds libc_cv_gcc_unwind_find_fde (I'm curious if this last bit
is still needed?).
Please figure it out and be sure. You need it only if there are existing
old C++ binaries that have references to _Unwind_Find_FDE. If
The following changes adds a few defines so __USE_FILE_OFFSET64
works properly on hppa.
Both the log entries and the patch here are botched. You must test your
patches before you send them. Please observe the change log conventions
more closely. Your entries have inadequate detail and are
How the patch it botched?
Look at the name of the file it creates.
I admit the following errors in the changelog:
a- Missing : after the file name and before the descriptive text.
b- Insuffient detail.
Yes.
Do you use the term 'canonical' to mean 'simplified' or rather
I think this should have been fixed by this libc change:
2000-01-08 Mark Kettenis [EMAIL PROTECTED]
* sysdeps/mach/hurd/setitimer.c (quantize_timeval): New function.
(setitimer_locked): Use it to quantize the timer values. Use
quantized timer values to check if the
I don't know the debian magic required to refile these two reports
as wishlist items, but that's what should be done.
This is just a fact about cross-compiling. The program that generates the
zoneinfo database to install is cross-compiled as part of the libc package,
so you are just out of luck. I think this report should be closed, and
just report whatever problems there are with native compilation separately.
I think that getsockopt in the libc for hurd is in fact ok (given the
current interfaces). I believe the problem reported was in the hurd
(pfinet), not in libc, and was fixed anyway a while ago.
If the reporter or maintainer concurs, please close this report.
msync is not in fact supported on the hurd. If you try it you'll see it's
a stub (always returns ENOSYS). An autoconf check for msync on the hurd
will not find it.
It is certainly the case that sysv-style ipc and shared memory are not
implemented on the hurd, and are not likely to be implemented any time soon.
We don't know of any particularly desireable things that sysv ipc provides
that can't be done another way (unix-domain sockets, pipes, etc, even
I've checked in a different fix for this to libc 2.1, that I think is
correct and avoids some more busy-work. But I have not tested this code at
all beyond compiling it, so please let me know how it is. I think the
comments in the new code explain the rationale.
The problem is, with this patch screen stops working again (same symptoms as
before, maybe setsid() stopped working again).
Sigh. Please send us a fresh test case (simple program) that you have
verified exhibits the bug with the current libc and hurd.
think getty should be the one to do it.
I checked in the following change, but haven't tested.
1999-09-22 Roland McGrath [EMAIL PROTECTED]
* getty.c (main): Make TTY our controlling terminal with TIOCSCTTY.
D'oh! Ok, I reverted that change and checked in your other fix to login.
But why did the extra ioctl do harm?
On Sat, Sep 18, 1999 at 07:05:12AM -0400, Roland McGrath wrote:
Well, Thomas and I uncovered some bugs.
Is there a public place that you and Thomas discuss Hurd-ish stuff?
Well, this stuff was discussed on this very list, and tracked in the BTS.
We do have an internal list for discussions
39 matches
Mail list logo
