Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-746135 ] dirent d_name should be array instead of pointer
|
From: SourceForge.net <no...@so...> - 2003-06-18 14:09:35
|
Bugs item #746135, was opened at 2003-05-30 11:04 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=746135&group_id=2435 Category: mingw runtime Group: Known bugs >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Earnie Boyd (earnie) Assigned to: Earnie Boyd (earnie) Summary: dirent d_name should be array instead of pointer Initial Comment: Based on several references including http://www.cygwin.com/ml/cygwin/2001-02/msg01372.html the d_name field should be a char array instead of a char *. In order to change this mingwex/dirent.c needs changed as well. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2003-06-18 10:09 Message: Logged In: YES user_id=15438 The problem you report has caused modification in some fashion in the official CVS for the given package. The w32api and mingw-runtime official CVS reside in the winsup CVS directory tree for Cygwin. Those package CVS trees are periodically merged into the MinGW CVS tree. If you still find problems then please open a new report. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-05-31 20:17 Message: Logged In: YES user_id=11494 I thing you are making an unsupported assumption about the 'standard' definition of struct dirent. See this (from Bruno Haible) http://sources.redhat.com/ml/libc-alpha/2002- 07/msg00097.html and the Open Group spec http://www.opengroup.org/onlinepubs/007904975/bas edefs/dirent.h.html In newlib this is what I found for dirent.d_name: decstation: char d_name[MAXNAMLEN + 1]; linux: char d_name[MAXNAMLEN + 1]; rtems: char d_name[NAME_MAX + 1]; sparc64: char d_name[MAXNAMLEN + 1]; sun4: char d_name[MAXNAMLEN + 1]; sysvi386: char d_name[1]; I agree that char[256} makes some sense if we are always going to use fullpath (as mingw's opendir does): Are you intending to submit a patch?. gcj and gcc's pch support use dirent (and DIR) so would need to test for regression there. Danny ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2003-05-31 08:21 Message: Logged In: YES user_id=15438 The latter of course. dirent.h will need to include limits.h to have PATH_MAX defined. Earnie. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-05-31 04:29 Message: Logged In: YES user_id=11494 Are you suggesting this : char d_name[] or this char d_name[MAX_PATH+1] The former shouldn't make any difference. The latter does, and as you indicate will mean changing dirent.c. Danny ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2003-05-30 16:58 Message: Logged In: YES user_id=15438 This code snippet is why it matters: <snippet packge="make" file="dir.c"> #ifdef __MINGW32__ /* FIXME: * The current 3.0 and previous versions of the MinGW runtime provide * a broken dirent structure that has d_name as a char * instead of * a char []. This work around should not be needed beyond MinGW * runtime version 3.0. */ d->d_name = xmalloc(len); #endif FAKE_DIR_ENTRY (d); #ifdef _DIRENT_HAVE_D_NAMLEN d->d_namlen = len - 1; #endif #ifdef _DIRENT_HAVE_D_TYPE d->d_type = DT_UNKNOWN; #endif memcpy (d->d_name, df->name, len); </snippet> d->d_name is an invalid pointer without the __MINGW32__ hack. Earnie. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-05-30 16:18 Message: Logged In: YES user_id=11494 I'll repeat the question that wqas asked on the cygwin list: > I agree that it's technically wrong if it's defined as a <char *>, > but I'd be interested if Reuben could give an illustration of why > it matters. I'd be interested as well. Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=746135&group_id=2435 |