2016-03-28 18:42 GMT-07:00 Juan Francisco Cantero Hurtado :
> @@ -448,6 +501,7 @@ go/pkg/bootstrap/pkg${GOCFG}/bootstrap/c
> go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/arm64.a
> go/pkg/bootstrap/pkg${GOCFG}/bootstrap/compile/internal/big.a
> go/pkg/bootstrap/pkg${GOCFG}/bootstrap/co
I seem to recall a bug where some CPU models don't properly set
registers after a CPUID instruction (e.g.,
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/locore.s#rev1.150).
Is it possible this CPU is one of those? Maybe Go needs similar
workarounds?
A way to test that hypothesis
ok with me if none of the test builds expose brokenness.
On Sun, Jun 29, 2014 at 9:19 AM, Joel Sing wrote:
> Longer answer, these particular ones should be - all of the source
> (including 386, amd64, arm, etc) always get installed. However, the ones
> you've spotted (runtime/z*.c) are generated during the build and should
> be only installed for the gi
On Fri, Jun 20, 2014 at 08:44:11PM +1000, Joel Sing wrote:
> Index: pkg/PFRAG.amd64
> ===
> RCS file: /cvs/ports/lang/go/pkg/PFRAG.amd64,v
> retrieving revision 1.3
> diff -u -p -r1.3 PFRAG.amd64
> --- pkg/PFRAG.amd64 2 Dec 2013 15:3
On Tue, May 27, 2014 at 2:14 PM, Jérémie Courrèges-Anglas
wrote:
> No proper license, approval required for patches and/or no
> redistribution of binary packages, bla, bla. I may not remember the
> details well enough; like most people that were interested in
> daemontools/qmail/djbdns/blah, but
Just curious, are the older POSIX standards available as man pages
too? Is there a way to install them side-by-side?
I'm by far most interested in the current up-to-date standard, but
being able to easily cross-reference older revisions is sometimes
handy. (E.g., when trying to make sure we're s
On Mon, Dec 30, 2013 at 12:13 PM, Pascal Stumpf wrote:
> I don't have logs, but the problem is that lang/g77 still emits
> references go __guard. The following diff should fix it (currently
> compiling math/octave).
Ah, makes sense. Diff looks ok to me assuming it builds successfully.
On Mon, Dec 30, 2013 at 9:47 AM, Christian Weisgerber
wrote:
> math/octave undefined reference to `__guard'
That's odd. Can you send me the build logs from this (or put them
somewhere I can access them)?
On Sun, Aug 18, 2013 at 2:43 AM, patrick keshishian wrote:
> + bt::timeval::timeval(const ::timeval &t)
> +- : tv_sec(t.tv_sec), tv_usec(t.tv_usec)
> +-{ }
> ++{ tv_sec = t.tv_sec; tv_usec = t.tv_usec; }
What's the point of these changes?
Looks ok to me, but I haven't tested it or anything.
On Fri, Aug 9, 2013 at 10:26 AM, Ian Darwin wrote:
> Sharper cluestick from matthew@.
>
> OK now?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/smtp-vilter/Makefile,v
> ret
On Fri, Aug 9, 2013 at 9:45 AM, Ian Darwin wrote:
> +-LDADD+= -nostdlib
> ++LDADD+= --nodefaultlib
Hm, I would think this needs to be "-nodefaultlibs" instead of
"--nodefaultlib" (i.e., only one hyphen and add the s).
On Thu, Jul 18, 2013 at 9:56 AM, Stuart Henderson wrote:
> On 2013/07/18 22:48, Jonathan Gray wrote:
> > @comment lib/libgtest.a
> > @comment lib/libgtest_main.a
> > +lib/libgtest.so
> > +lib/libgtest_main.so
>
> presumably the above 4 lines want replacing with
>
> @comment lib/libgtest.so
> @c
On Sun, Jul 7, 2013 at 8:36 PM, Anthony J. Bentley wrote:
> Upstream released another graphics plugin, video-glide64mk2, but I haven't
> made a port for it because it #includes , which doesn't seem to
> appear with either GCC 4.6 or clang.
>
Is the source file C or C++?
.
>
> Thanks a lot, Mathew.
>
> Please go ahead and commit it, you or Jasper ;)
>
> Ciao,
> David
>
>> On Mon, Jul 01, 2013 at 10:36:09AM -0700, Matthew Dempsky wrote:
>>> There's an unaligned word access in ninja's murmurhash implementation:
&g
There's an unaligned word access in ninja's murmurhash implementation:
https://github.com/martine/ninja/blob/master/src/hash_map.h
We need to change
unsigned int k = *(unsigned int *)data;
to
unsigned int k;
memcpy(&k, data, sizeof k);
and it should fix the unaligned accesses on st
This updates ninja to 1.3.3, which includes the OpenBSD patches
upstream and is the official version now used to build and test
Chrome.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/ninja/Makefile,v
retrieving revision 1.1.1.1
d
On Mon, May 13, 2013 at 7:08 PM, frantisek holop wrote:
> i would like to test the wip eclipse port
> but there is no way i could build that monster
> on my netbook. what are my options?
By wip eclipse port, do you mean
https://github.com/jasperla/openbsd-wip/tree/master/devel/eclipse?
If so, t
On Tue, May 7, 2013 at 2:50 PM, Matthias Kilian wrote:
> Spoiler: I'm not talking about Haskell but about ghc here.
To ask a possibly dumb question, what are our other options for
Haskell at the moment? E.g., it looks like x11/xmonad depends on
lang/ghc, so does removing ghc mean removing xmonad
On Thu, May 2, 2013 at 2:21 AM, David Coppa wrote:
> Ah... Didn't spot this.
No problem. I almost didn't notice it either until I decided to run
"grep python src/*.cc". :)
> So, ok dcoppa@ to import this.
Thanks, I'll import it tomorrow then. It's too late for me to risk a
botched cvs import
On Thu, May 2, 2013 at 12:40 AM, David Coppa wrote:
> Python is only needed for building ninja, so I've added MODPY_RUNDEP=No.
No, it's needed at run time too for the "ninja -t browse" functionality too.
> patch-bootstrap_py is not needed, 'cause ninja only wants libc,
> libm and libstdc++ that
On Wed, May 01, 2013 at 03:24:25PM -0700, Matthew Dempsky wrote:
> Attached is a port of the Ninja build system: http://martine.github.io/ninja/
D'oh, attached for real this time...
ninja.tar.gz
Description: application/tar-gz
Attached is a port of the Ninja build system: http://martine.github.io/ninja/
It needs ppoll() support, so you'll need to test with a recent release
snapshot containing libc.so.68.1.
The patches to add OpenBSD support have already been merged upstream
(https://github.com/martine/ninja/pull/565),
On Thu, Apr 11, 2013 at 4:54 AM, Kenneth R Westerback
wrote:
> On Thu, Apr 11, 2013 at 05:11:15AM +, Ted Unangst wrote:
>> Visiting www.apple.com displays the sad tab and this (repeating):
>> [5303:600661216:0411/005904:ERROR:omnibox_view_gtk.cc(431)] Not implemented
>> reached in virtual voi
On Thu, Sep 13, 2012 at 11:26:39PM +0100, Stuart Henderson wrote:
> Seeing this repeatably fail in my current i386 build, the go port hasn't
> changed, anyone have an idea what might be doing it?
As mentioned on icb, the Go linker doesn't set a PT_NOTE segment for
OpenBSD identification like it do
This fixes erlang to properly link its shared objects on OpenBSD, and
lets at least devel/rebar now build.
"make update-plist" tells me there's a new pkg/PLIST, but then fails
to write it for some currently unknown reason. I don't expect the
plist actually changes with this, but someone might dou
On Sun, Aug 26, 2012 at 10:25 PM, Scott McEachern wrote:
> ===> Installing groff-1.21p8 from /usr/ports/packages/amd64/all/
> Can't install groff-1.21p8 because of libraries
> |library c.65.0 not found
> | /usr/lib/libc.so.66.0 (system): bad major
> *** Error code 1
I suspect you compiled the gr
On Thu, Aug 16, 2012 at 7:55 AM, Brad Smith wrote:
> Update the GCC ports to sync the OpenBSD LIB_SPEC with the base gcc4
> for the new libpthread handling.
>
> Tested with gcc 3.3/4.2/4.6 on amd64.
Looks right to me. ok matthew
On Wed, Jun 6, 2012 at 6:25 AM, Stefan Sperling wrote:
> Any news?
I just committed devel/eclipse4/sdk to the openbsd-wip repo on github:
https://github.com/jasperla/openbsd-wip/tree/master/devel/eclipse4/sdk
This port is based on the recent 4.2 release instead of 4.1.2. Some
very quick testing
uilt against libc.so.65.0, but xfwm4 is still built against
libc.so.64.2.)
On Sat, Jun 23, 2012 at 1:11 AM, Matthew Dempsky wrote:
> On Sat, Jun 23, 2012 at 12:21 AM, Steven Mestdagh wrote:
>> just upgraded to the latest amd64 snapshot and packages.
>> has anyone else seen this e
On Sat, Jun 23, 2012 at 12:21 AM, Steven Mestdagh wrote:
> just upgraded to the latest amd64 snapshot and packages.
> has anyone else seen this error?
Sorry, that's my fault. :( I fixed posix_memalign() in libc to handle
large alignment requests. I knew glib would start taking advantage of
it,
(FYI, naddy@ already helped me with a bulk build test of this diff;
I'm just waiting on code reviews from a few developers now.)
On Mon, Jun 4, 2012 at 3:58 AM, Brett wrote:
> In case it is helpful, stuff I used a lot since rebuilding (and all working
> as before):
>
> xxxterm, mplayer, dnsmasq,
Diff below adds mbsnrtowcs() and wcsnrtombs(), which are new POSIX
2008 functions. I'd appreciate if someone could run this through a
bulk build and let me know if anything breaks or misbehaves.
Thanks!
Index: include/wchar.h
===
R
On Sun, May 20, 2012 at 2:26 PM, Stefan Unterweger wrote:
> You have missed a build dependency on 'archivers/unzip'.
Good catch, thanks. I'll fix that in the next version I mail out.
> However, even if everything seems to build, it still fails at the end
> when trying to install it. It seems as
On Tue, May 8, 2012 at 7:43 PM, Brett wrote:
> I am wondering if this will work ok the other way round?
In theory, GCC and PCC should implement the same ABI and so it should
work either way.
In practice, good luck.
Oh even if it's not signed that ternary branch will still be in code. I
see. Hm.
On May 10, 2012 9:23 AM, "Matthew Dempsky" wrote:
I'm pretty sure unsigned int is never a signed type.
On Thu, Mar 15, 2012 at 3:19 AM, Marc Espie wrote:
> #define __glibcxx_max(T) \
> - (__glibcxx_signed (T) ? ((T)1 << __glibcxx_digits (T)) - 1 : ~(T)0)
> + (__glibcxx_signed (T) ? \
> + (T)1 << (__glibcxx_digits (T) - 1)) - 1) << 1) + 1) : ~(T)0)
> +
How about (T)(((unsigned T)1 << __
file from the original mail.)
On Fri, May 04, 2012 at 02:57:22PM -0700, Matthew Dempsky wrote:
> Attached is a port for Eclipse SDK 4.1.2. I've only tested it on
> amd64, but it should (might?) work on i386 too. For the time being,
> there's no upstream for the "eclipse
On Tue, Apr 24, 2012 at 2:42 PM, Marc Espie wrote:
> Well, yuck, this makes for ways too many extra processes just for that.
There are no more processes than your wrapper program, and only two
more execs of /bin/sh. Considering make's primary task is forking and
exec'ing /bin/sh processes, I doub
On Thu, Apr 19, 2012 at 7:26 AM, Marc Espie wrote:
> On Thu, Apr 19, 2012 at 02:57:57PM +0100, Stuart Henderson wrote:
>> On 2012/04/19 15:42, Marc Espie wrote:
>> > Yeah, the only issue so far is that the make-wrapper process is C code, so
>> > it needs to be compiled and deployed on every host
>
Diff below updates CGAL from 3.8 to 3.9. A few remarks:
* cgal-3.8 has to be uninstalled before cgal-3.9 can be built. The
package tries to include older installed headers from
/usr/local/include before the newer packaged headers, so many
prototypes are missing or wrong. (I spent
On Wed, Nov 23, 2011 at 9:04 AM, Mark Kettenis wrote:
> Hard to tell if you don't explain what the problem is,
The problem is clang++ is stricter about C and C++ rules than GCC is.
E.g., it doesn't like conflicting prototypes, whereas GCC will happily
ignore them in certain cases. See
http://mar
On Tue, Oct 18, 2011 at 12:33 AM, Stuart Henderson wrote:
> nothing to do with systrace, you need to uninstall samba
> and/or .libs-samba before building.
Not entirely true. systrace only supports extracting strings up to
8192 bytes long, and that includes inspecting arguments to execve(2).
When
bsd.port.mk no longer warns about xz/sparc issues, so it seems like
bsd.port.mk.5 shouldn't need to either.
ok?
Index: bsd.port.mk.5
===
RCS file: /home/mdempsky/anoncvs/cvs/src/share/man/man5/bsd.port.mk.5,v
retrieving revision 1.28
Fixes a few minor Makefile issues I noticed while looking at this
again:
- Doesn't need cmake to build.
- Pass VERSION=${V} to qmake so that the embedded version strings
will be consistent rather than varying by build date.
- No need to run ${SUBST_CMD} on openscad.pro; there are no
On Sat, Jul 23, 2011 at 9:43 AM, Markus Lude wrote:
> systrace: deny user: markus, prog: /usr/local/bin/gtar, pid:
> 25619(0)[31757], policy: /usr/bin/make, filters: 197, syscall:
> native-mkdirat(318), args: 24
> /usr/local/bin/gtar: git-1.7.5: Cannot mkdir: Operation not permitted
This is a kno
On Sat, Jul 9, 2011 at 8:23 PM, Piotr Sikora wrote:
>> I started looking at this myself a few days ago in case it
>> might be any use for hibernate support (then I spotted it was
>> C++ and figured probably not) so I had half a port in my
>> tree already ;-)
>
> It comes with C bindings (snappy-c.
On Wed, Jun 15, 2011 at 3:11 PM, Amit Kulkarni wrote:
> devel/coccinelle?
That looks awesome. Has anyone played with using it for OpenBSD code
(e.g., kernel and base)?
On Thu, Apr 28, 2011 at 2:39 PM, Landry Breuil wrote:
>> 3. Should I make a separate RenderTexture port instead, and patch
>> OpenCSG to depend on that?
>
> That would be better, if more stuff want to depend on it later. If not..
> your call.
I think I'll leave it bundled for the time bein
On Thu, Apr 28, 2011 at 3:13 PM, Landry Breuil wrote:
> Yes for the latter.
Will do then.
> Bah, CGAL packages so many headers..
Yeah... =/
If you think that's bad, you should check out my OpenCASCADE port:
https://github.com/mdempsky/openbsd-stuff/blob/master/ports/cad/opencascade/pkg/PLIST
h
Attached is a port for OpenSCAD, "The Programmers Solid 3D CAD
Modeller". It depends on my two other outstanding ports,
graphics/opencsg and math/cgal. Also, as with those, you can find the
port on my github page at
https://github.com/mdempsky/openbsd-stuff/tree/master/ports/cad/openscad
ok?
o
The attached port is for the Computational Geometry Algorithms Library
(see http://www.cgal.org). You can also find my port on github at
https://github.com/mdempsky/openbsd-stuff/tree/master/ports/math/cgal.
Be advised that this port depends on fenv.h support in libm, which
martynas@ just committ
Ping?
On Mon, Apr 18, 2011 at 03:08:42PM -0700, Matthew Dempsky wrote:
> Attached is a port for graphics/opencsg; you can also find it at
> https://github.com/mdempsky/openbsd-stuff/tree/master/ports/graphics/opencsg
>
> The port's pretty simple, but a few things I want to chec
Attached is a port for graphics/opencsg; you can also find it at
https://github.com/mdempsky/openbsd-stuff/tree/master/ports/graphics/opencsg
The port's pretty simple, but a few things I want to check first:
1. The port only builds a shared object; should/must I patch it to
build a static
On Fri, Apr 08, 2011 at 12:43:03PM -0500, Amit Kulkarni wrote:
> I am in the process of updating llvm+clang from 2.8 ==> 2.9
> (maintainer is ports@).
jsg@ already has an update for this. I believe he's just checking for
broken dependencies now.
> Will some guru please find time to investigate t
On Tue, Mar 29, 2011 at 8:15 AM, Federico G. Schwindt wrote:
> Comments? Any OKs?
I think this changes the ABI, so you should probably bump the soname
if you're going to commit this.
However, it seems like a deliberate decision on their part to omit the
virtual tag here (not familiar with conte
Is anyone working on (or have plans to work on) updating the Eclipse
port? The version in tree appears to have languished behind quite a
bit.
FreeBSD appears to have a port for 3.6.1; haven't looked yet how
useful it is for OpenBSD though:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/eclipse-
On Tue, Mar 15, 2011 at 9:35 AM, Manuel Giraud
wrote:
> Here's the new version of emacs 23 port. Tested and ok on i386 GENERIC.MP
In post-install, since bin/emacs and bin/emacs-${VERSION} are hard
linked to the same file, you only need to chmod -t one of them.
Shouldn't you get rid of the REVISI
On Thu, Mar 10, 2011 at 6:46 AM, Manuel Giraud
wrote:
> It is an obsolete feature but it seems to be caused by the emacs install
> process. Don't know if it worth the effort to fight for it upstream.
post-install can easily fix it up.
However, I don't understand exactly what @bin signifies, so I
On Wed, Mar 9, 2011 at 5:07 AM, Manuel Giraud
wrote:
> Anyone to test on other archs (and eventually, we'll have more recent
> emacs in OpenBSD 5.0) ?
Seems to work on amd64.
I noticed that "make port-lib-depends-check" says that the X11-xcb
WANTLIB is extraneous.
Also, is it correct that bin/e
Attached is a port for dfu-programmer (http://dfu-programmer.sf.net/).
To build it successfully, you'll need to ensure you have r1.8 or newer
of /usr/include/stdarg.h installed.
I've tested on amd64 by successfully updating the 8u2 firmware on my
Arduino Uno.
(I know the ports tree is still locke
The diff below updates chromium to 9.0.597.107 (the latest stable
channel release), which fixes multiple security issues[1].
Additionally, it removes the vestigial LINK=/usr/bin/g++ environment
variable, enables SSE2 support on amd64, and fixes a bad #ifdef patch
(noticed by a failed attempt to bu
One of my coworkers got me interested in CNC milling, so I've been
looking into various 3D CAD/CAM software and working on porting them
to OpenBSD. They're still very much WIP (very sloppy makefiles,
require amd64-specific patches to base to add functionality, probably
non-functional in some cases
On Wed, Feb 16, 2011 at 11:00 AM, Amit Kulkarni wrote:
> I did as Matthew said. I just defined the checks to be 0, then
> followed rebuilding gcc4 instructions in FAQ/current.html by
> rebuilding the libstdc++ headers (rm -rf /usr/include/g++ etc...).
I think we can just get rid of the *_{CHECK,D
On Tue, Feb 15, 2011 at 11:57:44PM +0100, Marc Espie wrote:
> Finding out why it doesn't work with g++ from src would be
> the correct approach.
Investigating further, it seems to boil down to _GLIBCXX_USE_C99_CHECK
in /usr/include/g++/*/bits/os_defines.h. Including from base
effectively feeds
I know the trees locked right now, but I thought I'd send this out now
so it doesn't get lost.
Right now, clang++ tries to use libstdc++ from base (from g++ 4.2.1),
but even incredibly trivial programs fail to compile with it (e.g.,
hello world using iostream). Using the libstdc++ from ports (i.e
On Mon, Jan 24, 2011 at 03:43:30PM +, Federico G. Schwindt wrote:
> +--- net/socket.c.origMon Jan 24 15:34:58 2011
> net/socket.c Mon Jan 24 15:35:01 2011
> +@@ -195,7 +195,7 @@ static int net_socket_mcast_create(struct sockaddr_in
> + /* Force mcast msgs to loopback (eg.
On Mon, Sep 20, 2010 at 12:01 PM, Todd C. Miller
wrote:
> Apparently gcc 3.x doesn't like:
>
> const char *restrict addresses[]
>
> But is OK with:
>
> const char **restrict addresses
I'm pretty sure you want "const char * restrict * addresses" instead.
The diff below updates surf to 0.4.1, notably fixing GMail support for
me.
ok?
Index: Makefile
===
RCS file: /cvs/ports/www/surf/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile7 Jun 2010 07:24:00 -
On Tue, Jul 27, 2010 at 2:45 AM, Manuel Giraud
wrote:
> New version with correct WANTLIB and LIB_DEPENDS usage and a "wishful
> thinking" remove of the propolice workaround for powerpc.
Any update on this port? I just built it on amd64, and it seems okay so far.
On Sun, May 9, 2010 at 9:28 AM, Edd Barrett wrote:
> +#if defined(__OpenBSD__)
> -+ if (close(apm_fd) == -1)
> ++ if ((apm_fd != NULL) && (close(apm_fd) == -1))
> + warn("cannot close /dev/apm");
> +#endif
It seems wrong to use NULL (a pointer value) as a file descriptor
Would it be difficult to make it instead just print a warning about
userldt instead of erroring out?
On Fri, Sep 5, 2008 at 8:54 PM, Rajneesh N. Shetty
<[EMAIL PROTECTED]> wrote:
> I coud'nt install Google's Chrome browser on my machine
Chrome only works on Windows. Source code builds some framework stuff
on some other platforms, but nothing useful yet.
Give it a few months.
On Mon, Jun 30, 2008 at 8:31 AM, Christian Weisgerber
<[EMAIL PROTECTED]> wrote:
> A grep over a recent set of amd64 bulk build logs shows these ports
> generating warnings that indicate possible 64-bit problems:
I'm looking at the Erlang port's build logs, and I see some "warning:
cast from point
On Sun, Apr 27, 2008 at 12:53 AM, Predrag Punosevac
<[EMAIL PROTECTED]> wrote:
> I hate to disagree with somebody who sounds like my fellow countryman but
> DRM has NO use. I also teach at the University and I some time prepare
> slides too which use over layers and even more fancy stuff. Any deca
On Sat, Apr 26, 2008 at 6:29 PM, Zvezdan Petkovic <[EMAIL PROTECTED]> wrote:
> Replacing a protection with a message of intent of the author is probably a
> good idea.
Maybe for the xpdf maintainer (e.g., a --soft-drm configure option),
but that definitely seems way too intrusive a patch for main
On Sun, Apr 20, 2008 at 6:52 PM, <[EMAIL PROTECTED]> wrote:
> I didn't see anything conclusive in that thread... just an allusion
> toward a tinydns licensing problem, specifically the file format.
djbdns (including tinydns) has been placed into the public domain; see
http://cr.yp.to/distributo
On Mon, Apr 14, 2008 at 3:38 PM, Matthew Dempsky <[EMAIL PROTECTED]> wrote:
> patch below adds a gtk flavor for using the gtk toolkit instead of the
> default one. I'm not sure about the LIB_DEPENDS part though; I just
> put the major versions from the system I tested o
On Mon, Apr 14, 2008 at 12:42 PM, Eric Faurot <[EMAIL PROTECTED]> wrote:
> This is a work-in-progress port of emacs 22.2 based on a post
> by Fulvio Ciriaco. Contributions are most welcome.
Cool.
patch below adds a gtk flavor for using the gtk toolkit instead of the
default one. I'm not sure a
Is anyone working on an Emacs 22 port? I thought I'd check before
making a redundant effort.
On Sat, Apr 12, 2008 at 11:58 PM, Marco <[EMAIL PROTECTED]> wrote:
> Do you have notice, howto work fine the device in Subject?
http://www.openbsd.org/faq/faq14.html#flashmem
This builds, installs, and runs fine on amd64 for me.
On Wed, Apr 9, 2008 at 12:54 PM, Jon Olsson <[EMAIL PROTECTED]> wrote:
> Attached is a patch which updates Erlang to the latest release R12B-2, for
> more
> info: http://www.erlang.org/download/otp_src_R12B-2.readme
>
> Makefile
On Wed, Apr 2, 2008 at 4:10 PM, Mike Erdely <[EMAIL PROTECTED]> wrote:
> For what it's worth, that section of code was wrapped in:
> #ifdef __MINGW32__
> char *strdup...
> #endif /* def __MINGW32__ */
Right, that's why I said:
> > (Of course, OpenBSD provides strdup in libc, so
> > this cod
On Wed, Apr 2, 2008 at 2:48 PM, Mike Erdely <[EMAIL PROTECTED]> wrote:
> -@@ -344,7 +344,7 @@ char *strdup( const char *s )
> -
> -if (result != NULL)
> -{
> -- strcpy( result, s );
> -+ strlcpy( result, s, sizeof(result) );
> -}
> -
> -return( result );
It seems
85 matches
Mail list logo
