389-ds-base

#47923 Wrong type of env due to missing #ifdef
Closed: wontfix by mreynolds. Opened by tautschnig.

Closed: wontfix
Reopen Issue

Hello,

While building the Debian package 389-dsgw using our research compiler infrastructure the following error was flagged:

[...]
/include/nspr -I/usr/include -I/usr/include -I/usr/include/nss -I/usr/include/nspr -I/usr/include/nspr -I../include -I../include/base -DXP_UNIX -DPROPERTYDIR=\"/usr/share/dirsrv/properties/dsgw\" -DHTMLDIR=\"/usr/share/dirsrv/dsgw/html\" -DCOOKIEDIR=\"/var/run/dirsrv/dsgw/cookies\" -DCONFIGDIR=\"/usr/share/dirsrv/dsgw/config\" -DSECURITYDIR=\"/etc/dirsrv/dsgw\" -DCGIBINDIR=\"/usr/lib/x86_64-linux-gnu/dirsrv/dsgw-cgi-bin\" -DCONTEXTDIR=\"/etc/dirsrv/dsgw\" -DINSTCONFIGDIR=\"/etc/dirsrv\" -DMANUALDIR=\"/usr/share/dirsrv/manual\" -DCGIURIBASE=\"/dsgwcmd\" -DMANUALSUBDIR=\"dsgw\" -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c -o edit.o ../edit.c
file ../edit.c line 30: envp argument expected to be pointer type, but got `signed int'

As the C standard requires the third argument to be of a pointer type, the compiler may generate inappropriate code. The cause of this problem is that the #ifdef only disables the KnR type declaration, but not the parameter declaration. This code can be reviewed here:

https://git.fedorahosted.org/cgit/389/dsgw.git/tree/edit.c#n33

The suggested modification would be enclosing the parameter declaration in an #ifdef as well.

Best,
Michael

Thank you, Michael.
If you already have a working version, is it possible to attach the patch to this ticket?

A first patch is attached, but I am only about to check this one, further changes may be required. I'll provide updates ASAP.

The updated patch now seems to sort out all instances of the problem described above. There's now an issue with secglue.c, but that is a different problem (duplicate and conflicting definitions of functions, but that appears to be intended.)

Best,
Michael

I scanned the source code and found more files sharing the same #ifdef DSGW_DEBUG issue:
auth.c, csearch.c, lang.c, newentry.c, search.c, tutor.c

Are there any particular reason why you chose the 3 files?
domodify.c | 6 +++++-
dosearch.c | 6 +++++-
edit.c | 6 +++++-

Thanks,
--noriko

I am just checking an updated version, after working around the secglue issue.

So this is the final diffstat:

csearch.c | 6 +++++-
domodify.c | 6 +++++-
dosearch.c | 6 +++++-
edit.c | 6 +++++-
newentry.c | 7 ++++++-
search.c | 6 +++++-
6 files changed, 31 insertions(+), 6 deletions(-)

Removing secglue.c as dependency in all cases in Makefile.am allows for a clean build. I don't know what secglue.c would be needed for, and things can only work when relying on the specific behaviour of the Linux linker (other linkers might pick the wrong definition; or actually any linker picking a definition from secglue.c will cause a failure at runtime).

Best,
Michael

I see. Thank you so much for your patch!

Metadata Update from @nhosoi:
- Issue set to the milestone: 389-dsgw 1.1.12

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1254

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)
Metadata
None
None
None
None
Highest
None
Community
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.