Bug#858529: libc6: fgets repeats content after fork on stretch only

2017-03-22 Thread Neil Spring
Package: libc6
Version: 2.24-9
Severity: normal

Dear Maintainers,

I'm testing a programming exercise for students, and found failed tests
that I believe are due to libc6.  I retried the minimal test case on
every machine I have access to, and found that only my two Debian Stretch
machines failed, then took a clean vagrant Jessie box, confirmed correct
behavior, updated to Stretch, and reproduced the error.

I expect the following code to print its input, once.  Instead, it 
prints lines two through four twice. (abcdbcd).

#include 
#include 
#include 
#include 

int main() {
  char buf[255];
  int ln=1;
  int status;
  FILE *f;

  f = fopen("/tmp/fourlines", "w");
  fprintf(f, "a\nb\nc\nd\n");
  fclose(f);

  f= fopen("/tmp/fourlines", "r");
  printf("%d: %s", ln++, fgets(buf, 255, f));

  if(fork() == 0) { exit(1); }
  wait(&status);

  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
  exit(0);
}

Output on my two machines and vm with 2.24-9:

1: a
2: b
3: c
4: d
5: b
6: c
7: d

The behavior is consistent under the debugger; I don't see 
anything obvious in the FILE structure, and notice that a 
read occurs between the d and b (the end of input and when 
what should be old data is back in).

I plan to look into slightly older libc6 versions to find the 
regression, but that will take me some time.

This is sent from the virtual machine, to keep it as clean as 
possible.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:6.3.0-6

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.60
pn  glibc-doc  
ii  libc-l10n  2.24-9
ii  locales2.24-9

-- debconf information:
  glibc/restart-failed:
  glibc/kernel-too-old:
  glibc/upgrade: true
  glibc/restart-services:
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true



Bug#858529: minimal update narrows to libc6.

2017-03-23 Thread Neil Spring
I took a clean jessie install in vagrant (bento/debian-8.7), then rather than 
update everything to stretch, I apt-get install’ed only libc6 from stretch.  
Same result: four lines before the upgrade, seven lines, duplicating the last 
three, after.

Happy to share Vagrantfile and output, though I expect your skills are stronger 
than mine.

-neil



Bug#62826: libc6-dev: ntohl causes warning with -Wtraditional -O2 (bits/byteswap.h)

2000-04-22 Thread Neil Spring
Package: libc6-dev
Version: 2.1.3-8

This is a tricky one.  I think it's important, because
without it, any code that uses ntohl gets silly warnings.

When compiling the following code, using 
"gcc -O2 -Wtraditional tester.c"
I get the following warning.

The Warning:
---
tester.c: In function `main':
tester.c:4: warning: integer constant is unsigned in ANSI C, signed with 
-traditional

The Code:
---
int main() {
  unsigned int h = ntohl(12);
  return(h);
}

The Fix:
---
/usr/include/bits/byteswap.h, line 48:

/* Swap bytes in 32 bit value.  */
#define __bswap_constant_32(x) \
 x) & 0xff00) >> 24) | (((x) & 0x00ff) >>  8) | \
  (((x) & 0xff00) <<  8) | (((x) & 0x00ff) << 24))

should be changed to:
 x) & 0xff00U) >> 24) {etc.}

This macro seems to be the ultimate expansion of ntohl, and
causes the warning.  It's not clear to me that the change
to force that to be unsigned won't cause some other error.

other stuff:
uname: Linux poplar 2.2.13 #1 Sat Nov 20 12:44:19 EST 1999 i686 unknown
libc6: /lib/libc.so.6 -> libc-2.1.3.so

thanks,
-neil



Bug#111767: syslog.h bug persists

2002-09-18 Thread Neil Spring

2.2.5-14.3 still has the sys/syslog.h SYSLOG_NAMES bug.

it'd be great if someone can apply:

-   char*c_name;
+   const char  *c_name;

or report it upstream.  

I realize there are bigger problems to deal with; thanks for
your hard work.

-neil




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]