[PATCH] Win32 miniperl: delay loading for Winsock, and then remove it

[p5pRT]

Migrated from rt.perl.org#115246 (status was 'resolved')

Searchable as RT115246$

[p5pRT]

From @bulk88

Created by @bulk88

See patch's message\, and http​://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194007.html for which there were no responses.

Perl Info

``` Flags: category=core severity=low Site configuration information for perl 5.17.5: Configured by Owner at Mon Oct 8 03:07:26 2012. Summary of my perl5 (revision 5 version 17 subversion 5) configuration: Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -G7 -GL -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T', optimize='-MD -Zi -DNDEBUG -O1 -G7 -GL', cppflags='-DWIN32' ccversion='13.10.6030', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl517\lib\CORE" -machine:x86' libpth="C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib" libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl517.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl517\lib\CORE" -machine:x86' Locally applied patches: @INC for perl 5.17.5: C:/perl517/site/lib C:/perl517/lib . Environment for perl 5.17.5: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\perl517\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin\prerelease;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem; PERL_BADLANG (unset) SHELL (unset) ```

[p5pRT]

From @bulk88

0001-Win32-miniperl-delay-loading-for-Winsock-and-then-re.patch

```diff From 7d7ee1cf056f92c952db6e8a9986e4a02025eb60 Mon Sep 17 00:00:00 2001 From: Daniel Dragan Date: Sat, 13 Oct 2012 19:37:33 -0400 Subject: [PATCH] Win32 miniperl: delay loading for Winsock, and then remove it Slim down the image and speed up start up time for Win32 miniperl by removing Winsock. Also if the build process on Win32 in the future requires sockets, commenting one line in win32.h will turn sockets back on for miniperl, but this time with delay loading on VC Perl. The only casulty of no sockets for Win32 miniperl was figuring out the computer's name in win32/config_sh.PL. A workaround by using an ENV var was implemented. The purpose of this commit is to speed up the build process of Perl. As said in the comment in win32.h, the WIN32_NO_SOCKETS macro is incomplete in implementation. It is only removed winsock from being linked in in miniperl, not full Perl. PERL_IMPLICIT_SYS (specifically PerlSock in win32/perlhost.h) and makedef.pl's hard coded list of win32_* function exports cause winsock to still be linked in with even with WIN32_NO_SOCKETS on full perl. Both PERL_IMPLICIT_SYS (win32/perlhost.h) and makedef.pl would require changes to remove winsock from being linked in on full perl in the future. --- win32/Makefile | 2 +- win32/config_sh.PL | 8 ++++++-- win32/makefile.mk | 2 +- win32/win32.c | 8 ++++++++ win32/win32.h | 38 ++++++++++++++++++++++++++++++++++++-- win32/win32sck.c | 19 +++++++++++++++++++ 6 files changed, 71 insertions(+), 6 deletions(-) diff --git a/win32/Makefile b/win32/Makefile index cf83e9b..908f634 100644 --- a/win32/Makefile +++ b/win32/Makefile @@ -957,7 +957,7 @@ $(CONFIGPM) : $(MINIPERL) ..\config.sh config_h.PL ..\minimod.pl $(MINIPERL) : $(MINIDIR) $(MINI_OBJ) $(LINK32) -subsystem:console -out:$@ @<< - $(LINK_FLAGS) $(LIBFILES) $(MINI_OBJ) + $(LINK_FLAGS) $(DELAYLOAD) $(LIBFILES) $(MINI_OBJ) << $(EMBED_EXE_MANI) diff --git a/win32/config_sh.PL b/win32/config_sh.PL index 3733c47..d866f76 100644 --- a/win32/config_sh.PL +++ b/win32/config_sh.PL @@ -103,8 +103,12 @@ if (exists $opt{cc}) { } $opt{cf_by} = $ENV{USERNAME} unless $opt{cf_by}; -$opt{cf_email} = $opt{cf_by} . '@' . (gethostbyname('localhost'))[0] - unless $opt{cf_email}; +if (!$opt{cf_email}) { + my $computername = eval{(gethostbyname('localhost'))[0]}; +# gethostbyname might not be implemented in miniperl + $computername = $ENV{COMPUTERNAME} if $@; + $opt{cf_email} = $opt{cf_by} . '@' . $computername; +} $opt{usemymalloc} = 'y' if $opt{d_mymalloc} eq 'define'; $opt{libpth} = mungepath($opt{libpth}) if exists $opt{libpth}; diff --git a/win32/makefile.mk b/win32/makefile.mk index bd8e726..99366cf 100644 --- a/win32/makefile.mk +++ b/win32/makefile.mk @@ -1086,7 +1086,7 @@ $(MINIPERL) : $(MINIDIR) $(MINI_OBJ) $(CRTIPMLIBS) $(mktmp $(LKPRE) $(MINI_OBJ) $(LIBFILES) $(LKPOST)) .ELSE $(LINK32) -subsystem:console -out:$@ $(BLINK_FLAGS) \ - @$(mktmp $(LIBFILES) $(MINI_OBJ)) + @$(mktmp $(DELAYLOAD) $(LIBFILES) $(MINI_OBJ)) $(EMBED_EXE_MANI) .ENDIF diff --git a/win32/win32.c b/win32/win32.c index 3ee85a1..fdf6e85 100644 --- a/win32/win32.c +++ b/win32/win32.c @@ -2728,7 +2728,11 @@ win32_freopen(const char *path, const char *mode, FILE *stream) DllExport int win32_fclose(FILE *pf) { +#ifdef WIN32_NO_SOCKETS + return fclose(pf); +#else return my_fclose(pf); /* defined in win32sck.c */ +#endif } DllExport int @@ -3247,7 +3251,11 @@ extern int my_close(int); /* in win32sck.c */ DllExport int win32_close(int fd) { +#ifdef WIN32_NO_SOCKETS + return close(fd); +#else return my_close(fd); +#endif } DllExport int diff --git a/win32/win32.h b/win32/win32.h index 9d229db..c9852f8 100644 --- a/win32/win32.h +++ b/win32/win32.h @@ -13,6 +13,38 @@ # define _WIN32_WINNT 0x0500 /* needed for CreateHardlink() etc. */ #endif +#ifdef PERL_IS_MINIPERL +/* this macro will remove Winsock only on miniperl, PERL_IMPLICIT_SYS and + * makedef.pl create dependencies that will keep Winsock linked in even with + * this macro defined, even though sockets will be umimplemented from a script + * level in full perl + */ +# define WIN32_NO_SOCKETS +#endif + +#ifdef WIN32_NO_SOCKETS +# undef HAS_SOCKET +# undef HAS_GETPROTOBYNAME +# undef HAS_GETPROTOBYNUMBER +# undef HAS_GETPROTOENT +# undef HAS_GETNETBYNAME +# undef HAS_GETNETBYADDR +# undef HAS_GETNETENT +# undef HAS_GETSERVBYNAME +# undef HAS_GETSERVBYPORT +# undef HAS_GETSERVENT +# undef HAS_GETHOSTBYNAME +# undef HAS_GETHOSTBYADDR +# undef HAS_GETHOSTENT +# undef HAS_SELECT +# undef HAS_IOCTL +# undef HAS_NTOHL +# undef HAS_HTONL +# undef HAS_HTONS +# undef HAS_NTOHS +# define WIN32SCK_IS_STDSCK +#endif + #if defined(PERL_IMPLICIT_SYS) # define DYNAMIC_ENV_FETCH # define HAS_GETENV_LEN @@ -166,8 +198,10 @@ struct utsname { #define OP_BINARY O_BINARY /* mistake in in pp_sys.c? */ /* read() and write() aren't transparent for socket handles */ -#define PERL_SOCK_SYSREAD_IS_RECV -#define PERL_SOCK_SYSWRITE_IS_SEND +#ifndef WIN32_NO_SOCKETS +# define PERL_SOCK_SYSREAD_IS_RECV +# define PERL_SOCK_SYSWRITE_IS_SEND +#endif #define PERL_NO_FORCE_LINK /* no need for PL_force_link_funcs */ diff --git a/win32/win32sck.c b/win32/win32sck.c index 479d99e..9032a6d 100644 --- a/win32/win32sck.c +++ b/win32/win32sck.c @@ -82,31 +82,50 @@ start_sockets(void) wsock_started = 1; } +/* in no sockets Win32 builds, this fowards to replacements in util.c, dTHX + * is required + */ u_long win32_htonl(u_long hostlong) { +#ifdef MYSWAP + dTHX; +#else StartSockets(); +#endif return htonl(hostlong); } u_short win32_htons(u_short hostshort) { +#ifdef MYSWAP + dTHX; +#else StartSockets(); +#endif return htons(hostshort); } u_long win32_ntohl(u_long netlong) { +#ifdef MYSWAP + dTHX; +#else StartSockets(); +#endif return ntohl(netlong); } u_short win32_ntohs(u_short netshort) { +#ifdef MYSWAP + dTHX; +#else StartSockets(); +#endif return ntohs(netshort); } -- 1.7.9.msysgit.0 ```

[p5pRT]

From @steve-m-hay

I wonder if it would be better to not bother with the WIN32_NO_SOCKETS option\, and simply always remove sockets for miniperl (only)?

You've worked around the one current place in the build process that required sockets\, so it's really a question of how likely it is for any other such things (but having no easy workaround/alternative) to occur in the future.

Do any other porters with an interest in Windows and/or the build process have an opinion on this?

If it seems sufficiently unlikely then I personally see no point in the WIN32_NO_SOCKETS option since I don't think I'd ever want to build a (full) perl without sockets (and as noted in your patch\, that is not completely implemented anyway).

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @cpansprout

On Wed Oct 17 16​:16​:42 2012\, shay wrote​:

I wonder if it would be better to not bother with the WIN32_NO_SOCKETS option\, and simply always remove sockets for miniperl (only)?

You've worked around the one current place in the build process that required sockets\, so it's really a question of how likely it is for any other such things (but having no easy workaround/alternative) to occur in the future.

Do any other porters with an interest in Windows and/or the build process have an opinion on this?

Will it affect minitest?

--

Father Chrysostomos

[p5pRT]

From @jandubois

On Wed\, Oct 17\, 2012 at 4​:16 PM\, Steve Hay via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Do any other porters with an interest in Windows and/or the build process have an opinion on this?

I don't see the point in doing these micro-optimizations for miniperl\, as I never use it for anything but building Perl. But I don't have any objections either as long as miniperl can still build Perl. :)

Cheers\, -Jan

[p5pRT]

From @steve-m-hay

On Wed Oct 17 16​:20​:22 2012\, sprout wrote​:

On Wed Oct 17 16​:16​:42 2012\, shay wrote​:

I wonder if it would be better to not bother with the WIN32_NO_SOCKETS option\, and simply always remove sockets for miniperl (only)?

You've worked around the one current place in the build process that required sockets\, so it's really a question of how likely it is for any other such things (but having no easy workaround/alternative) to occur in the future.

Do any other porters with an interest in Windows and/or the build process have an opinion on this?

Will it affect minitest?

Good question. I guess there's little reason for minitest to be testing anything that isn't done during the build process anyway since miniperl is rarely (if ever?) used for anything other than building perl\, so in theory I think it shouldn't be affected.

However\, in practice (testing that theory out) I've just discovered that minitest is broken anyway (at least on Windows)​: with or without this patch I get​:

cd ..\t && ..\miniperl.exe -I..\lib harness base/*.t comp/*.t cmd/*.t io/*.t op/*.t pragma/*.t Can't load module IO\, dynamic loading not available in this perl.   (You may need to build a new perl executable which either supports   dynamic loading or has the IO module statically linked into it.) at ../lib/IO/Handle.pm line 266. Compilation failed in require at ../lib/IO/Handle.pm line 266. BEGIN failed--compilation aborted at ../lib/IO/Handle.pm line 266. Compilation failed in require at ../lib/TAP/Harness.pm line 8. BEGIN failed--compilation aborted at ../lib/TAP/Harness.pm line 8. Compilation failed in require at harness line 13. BEGIN failed--compilation aborted at harness line 13. NMAKE : fatal error U1077​: 'cd' : return code '0xff' Stop.

[p5pRT]

From @steve-m-hay

On Wed Oct 17 16​:27​:21 2012\, jdb wrote​:

On Wed\, Oct 17\, 2012 at 4​:16 PM\, Steve Hay via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Do any other porters with an interest in Windows and/or the build process have an opinion on this?

I don't see the point in doing these micro-optimizations for miniperl\, as I never use it for anything but building Perl. But I don't have any objections either as long as miniperl can still build Perl. :)

Indeed. I think the idea is to try to speed up the build process slightly\, but I suspect the gains are so slight as to not be noticeable. I haven't done any accurate timings\, but my human eye certainly hasn't noticed any difference.

But I agree there's nothing wrong with such changes as long as they don't break the build\, hence my wondering whether removing sockets from miniperl is likely to break anything in the future...

[p5pRT]

From @cpansprout

On Wed Oct 17 17​:01​:43 2012\, shay wrote​:

On Wed Oct 17 16​:20​:22 2012\, sprout wrote​:

On Wed Oct 17 16​:16​:42 2012\, shay wrote​:

I wonder if it would be better to not bother with the WIN32_NO_SOCKETS option\, and simply always remove sockets for miniperl (only)?

You've worked around the one current place in the build process that required sockets\, so it's really a question of how likely it is for any other such things (but having no easy workaround/alternative) to occur in the future.

Do any other porters with an interest in Windows and/or the build process have an opinion on this?

Will it affect minitest?

Good question. I guess there's little reason for minitest to be testing anything that isn't done during the build process anyway since miniperl is rarely (if ever?) used for anything other than building perl\, so in theory I think it shouldn't be affected.

However\, in practice (testing that theory out) I've just discovered that minitest is broken anyway (at least on Windows)​: with or without this patch I get​:

cd ..\t && ..\miniperl.exe -I..\lib harness base/*.t comp/*.t cmd/*.t io/*.t op/*.t pragma/*.t Can't load module IO\, dynamic loading not available in this perl. (You may need to build a new perl executable which either supports dynamic loading or has the IO module statically linked into it.) at ../lib/IO/Handle.pm line 266. Compilation failed in require at ../lib/IO/Handle.pm line 266. BEGIN failed--compilation aborted at ../lib/IO/Handle.pm line 266. Compilation failed in require at ../lib/TAP/Harness.pm line 8. BEGIN failed--compilation aborted at ../lib/TAP/Harness.pm line 8. Compilation failed in require at harness line 13. BEGIN failed--compilation aborted at harness line 13. NMAKE : fatal error U1077​: 'cd' : return code '0xff' Stop.

Interesting. minitest on Windows uses t/harness instead of t/TEST. In fact\, ‘make test’ also uses harness.

On Unix\, if the one-liner ‘./miniperl -w -Ilib -MExporter -e '\<?>'’ fails when making miniperl\, minitest is run automatically. I think the idea is to provide some inside into why miniperl is so badly broken when trying out perl on a not-yet- or vaguely- supported system.

win32/Makefile doesn’t do that. So I’m not so sure that minitest is meaningful on Windows.

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Wed Oct 17 17​:03​:18 2012\, shay wrote​:

On Wed Oct 17 16​:27​:21 2012\, jdb wrote​:

On Wed\, Oct 17\, 2012 at 4​:16 PM\, Steve Hay via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Do any other porters with an interest in Windows and/or the build process have an opinion on this?

I don't see the point in doing these micro-optimizations for miniperl\, as I never use it for anything but building Perl. But I don't have any objections either as long as miniperl can still build Perl. :)

Indeed. I think the idea is to try to speed up the build process slightly\, but I suspect the gains are so slight as to not be noticeable. I haven't done any accurate timings\, but my human eye certainly hasn't noticed any difference.

But I agree there's nothing wrong with such changes as long as they don't break the build\, hence my wondering whether removing sockets from miniperl is likely to break anything in the future...

If the build process ever involves internet connections (e.g.\, for custom builds with CPAN XS modules built statically into perl)\, that might be a problem.

But we could revert the change if that happens.

--

Father Chrysostomos

[p5pRT]

From @bulk88

On Wed Oct 17 17​:57​:08 2012\, sprout wrote​:

If the build process ever involves internet connections (e.g.\, for custom builds with CPAN XS modules built statically into perl)\, that might be a problem.

But we could revert the change if that happens.

There are 4 reasons I made the patch.

1. no sockets is easily turned off with one line if miniperl requires it in the future

2. provide delay loading of winsock to miniperl if sockets are turned back on

3. provide the framework for a no sockets full perl in the future if someone else demands one (business IT security policy) and does the remaining work themselves

4. either delay loading or no sockets at all will speed up the build process\, although it won't be human perceptible\, but is measurable\, atleast the PC is saving CPU power

I think Perl on DOS (DJGPP) compiled without sockets.

[p5pRT]

From @steve-m-hay

On Wed Oct 17 18​:32​:39 2012\, bulk88 wrote​:

On Wed Oct 17 17​:57​:08 2012\, sprout wrote​:

If the build process ever involves internet connections (e.g.\, for custom builds with CPAN XS modules built statically into perl)\, that might be a problem.

But we could revert the change if that happens.

There are 4 reasons I made the patch.

1. no sockets is easily turned off with one line if miniperl requires it in the future

2. provide delay loading of winsock to miniperl if sockets are turned back on

3. provide the framework for a no sockets full perl in the future if someone else demands one (business IT security policy) and does the remaining work themselves

4. either delay loading or no sockets at all will speed up the build process\, although it won't be human perceptible\, but is measurable\, atleast the PC is saving CPU power

I think Perl on DOS (DJGPP) compiled without sockets.

Ok\, I'll accept the WIN32_NO_SOCKETS option\, then​: testing PERL_IS_MINIPERL instead would hardly make the patch any simpler anyway\, and would be a little less flexible for the future.

However\, I have a problem with the patch when building with MinGW/gcc​: I'm getting three warnings per C file compiled from proto.h\, which don't normally appear​:

gcc -c -I.\include -I. -I.. -I..\lib\CORE -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\av.o ..\av.c In file included from ..\perl.h​:5043​:0\,   from ..\av.c​:24​: ..\proto.h​:5229​:4​: warning​: '__malloc__' attribute ignored [-Wattributes] ..\proto.h​:5234​:4​: warning​: '__malloc__' attribute ignored [-Wattributes] ..\proto.h​:5239​:4​: warning​: '__malloc__' attribute ignored [-Wattributes]

[p5pRT]

From @bulk88

On Fri Oct 19 00​:33​:26 2012\, shay wrote​:

Ok\, I'll accept the WIN32_NO_SOCKETS option\, then​: testing PERL_IS_MINIPERL instead would hardly make the patch any simpler anyway\, and would be a little less flexible for the future.

I created a WIN32_NO_SOCKETS specifically so the code isn't mixed with PERL_IS_MINIPERL making a nightmare if sockets must be turned on in the future.

However\, I have a problem with the patch when building with MinGW/gcc​: I'm getting three warnings per C file compiled from proto.h\, which don't normally appear​:

gcc -c -I.\include -I. -I.. -I..\lib\CORE -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\av.o ..\av.c In file included from ..\perl.h​:5043​:0\, from ..\av.c​:24​: ..\proto.h​:5229​:4​: warning​: '__malloc__' attribute ignored [-Wattributes] ..\proto.h​:5234​:4​: warning​: '__malloc__' attribute ignored [-Wattributes] ..\proto.h​:5239​:4​: warning​: '__malloc__' attribute ignored [-Wattributes]

The reason is the functions have an 'a' on them in embed.fnc. See this commit http​://perl5.git.perl.org/perl.git/commit/f54cb97a39f1a5849851e77a33524dfca2644cf5?f=embed.fnc . Previously (until my no sockets code) they were macro-ed out because MYSWAP was undef (instead use the native sockets library for local to network address conversion). I can't comment on a fix for the embed.fnc 'a' attribute warning. Since GCC no sockets builds of Perl are so rare\, normal GCC users will never see those warnings because those functions don't exist because ever POSIX OS on Earth has sockets\, right? The warnings should be corrected if someone knows if/how to do it.

[p5pRT]

From @steve-m-hay

On Fri Oct 19 01​:13​:39 2012\, bulk88 wrote​:

On Fri Oct 19 00​:33​:26 2012\, shay wrote​:

However\, I have a problem with the patch when building with MinGW/gcc​: I'm getting three warnings per C file compiled from proto.h\, which don't normally appear​:

gcc -c -I.\include -I. -I.. -I..\lib\CORE -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\av.o ..\av.c In file included from ..\perl.h​:5043​:0\, from ..\av.c​:24​: ..\proto.h​:5229​:4​: warning​: '__malloc__' attribute ignored [- Wattributes] ..\proto.h​:5234​:4​: warning​: '__malloc__' attribute ignored [- Wattributes] ..\proto.h​:5239​:4​: warning​: '__malloc__' attribute ignored [- Wattributes]

The reason is the functions have an 'a' on them in embed.fnc. See this commit

http​://perl5.git.perl.org/perl.git/commit/f54cb97a39f1a5849851e77a33524dfca2644cf5?f=embed.fnc . Previously (until my no sockets code) they were macro-ed out because MYSWAP was undef (instead use the native sockets library for local to network address conversion). I can't comment on a fix for the embed.fnc 'a' attribute warning. Since GCC no sockets builds of Perl are so rare\, normal GCC users will never see those warnings because those functions don't exist because ever POSIX OS on Earth has sockets\, right? The warnings should be corrected if someone knows if/how to do it.

I wasn't running a "no sockets perl" build. The warnings appear from the miniperl part of the normal build process...

I will have a look at fixing it myself later\, but I would be very happy if someone beat me to it :-)

[p5pRT]

From @bulk88

On Fri Oct 19 01​:19​:27 2012\, shay wrote​:

I wasn't running a "no sockets perl" build. The warnings appear from the miniperl part of the normal build process...

I will have a look at fixing it myself later\, but I would be very happy if someone beat me to it :-)

I won't be able to\, I didn't understand clearly enough what attribute malloc does or when to or not to use it. I also don't compile the interp with GCC. Also I'm not sure what else was incorrectly marked in that commit\, since if those 3 were tagged incorrectly\, maybe there are dozens more that only an expert would ID.

[p5pRT]

From @cpansprout

On Fri Oct 19 01​:57​:29 2012\, bulk88 wrote​:

On Fri Oct 19 01​:19​:27 2012\, shay wrote​:

I wasn't running a "no sockets perl" build. The warnings appear from the miniperl part of the normal build process...

I will have a look at fixing it myself later\, but I would be very happy if someone beat me to it :-)

I won't be able to\, I didn't understand clearly enough what attribute malloc does

It’s a compiler hint that tells it a function allocates stuff\, so the return value should not be ignored\, and possibly other things I don’t know about.

--

Father Chrysostomos

[p5pRT]

From @mauke

On 19.10.2012 15​:30\, Father Chrysostomos via RT wrote​:

On Fri Oct 19 01​:57​:29 2012\, bulk88 wrote​:

I won't be able to\, I didn't understand clearly enough what attribute malloc does

It’s a compiler hint that tells it a function allocates stuff\, so the return value should not be ignored\, and possibly other things I don’t know about.

Its main use is to inform the optimizer that the returned pointer cannot reference any other object (i.e. it can't alias anything). There's a separate warn_unused_result for warning about ignored return values.

Lukas

[p5pRT]

From @steve-m-hay

Thanks for the patch\, which is finally now applied in commit 19253ae62c. Thanks also to others for commenting on the __malloc__ attribute warnings. It looks to me like the three functions in question should simply never have had that attribute added in the first place since none of them do (or did) allocate any memory\, so I've changed the "a" to an "R" in embed.fnc in commit cd88b75a7a.

[p5pRT]

From [Unknown Contact. See original ticket]

Thanks for the patch\, which is finally now applied in commit 19253ae62c. Thanks also to others for commenting on the __malloc__ attribute warnings. It looks to me like the three functions in question should simply never have had that attribute added in the first place since none of them do (or did) allocate any memory\, so I've changed the "a" to an "R" in embed.fnc in commit cd88b75a7a.

[p5pRT]

@steve-m-hay - Status changed from 'open' to 'resolved'