clisp-devel — closed list for developers and testers

Re: status update

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-31 13:57:12 +0200]:
>
> First a word to GSoC: I'm of course sad that I didn't made it through
> the final evaluation, but it was definitely the right decision. I had
> not achieved the main goal (making a release, updating gnulib) and
> thus would've decided the same way (there was a checkbox asking about
> my own impression about the project status where I noted exactly this
> impression myself, too).

I am glad we agree here.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://www.dhimmitude.org http://americancensorship.org
http://mideasttruth.com http://truepeace.org http://thereligionofpeace.com
Diplomacy is the art of saying "nice doggy" until you can find a nice rock.

Re: status update

[Daniel J. <dan...@gm...>]

First a word to GSoC: I'm of course sad that I didn't made it through
the final evaluation, but it was definitely the right decision. I had
not achieved the main goal (making a release, updating gnulib) and
thus would've decided the same way (there was a checkbox asking about
my own impression about the project status where I noted exactly this
impression myself, too).


> BUFSIZ is a pretty standard constant for all string buffers.

Eh, can you support that? It's a standard constant for STREAM
buffers. This is even defined by the C (C99) standard. Using it for
anything that's not directly related to a stream thus seems wrong to
me.

The only thing that might be interpreted as "standard for [..] string
buffers" is this quote from the glibc documentation:

> Sometimes people also use BUFSIZ as the allocation size of buffers
> used for related purposes, such as strings used to receive a line of
> input with fgets (see Character Input). There is no particular
> reason to use BUFSIZ for this instead of any other integer, except
> that it might lead to doing I/O in chunks of an efficient size.

Though this too does not specify whether BUFSIZ will be small enough
to be put onto the stack. Moreover it's just in the documentation of a
single libc, there might be systems that have a huge BUFSIZ but only
provide limited stack space.



> Let us revisit this issue at a later date.
> I think the with_string_0 mechanism is good enough.
> If disagree, you will have to argue for it to be changed pervasively
> throughout CLISP.

with_string_0 is not involved here. I'm concerned by this (from regexi.c):

begin_system_call();
ret = (regmatch_t*)alloca((re->re_nsub+1)*sizeof(regmatch_t));
end_system_call();

re->re_nsub is the number of subexpressions, and if the regex is in
anyway "modifyable" by a malicious actor (e.g. a POST parameter for a
search field), then that actor could pass a regex with lots of
subexpressions, thus causing above alloca to produce a stack overflow
(in the best case).



> This is why we don't run gnulib-tool in that directory!
> We only ever run it in src.

Hm, I'm afraid that this not a good idea, at least not a scalable
one. Let me explain: We have modules because we don't want to have
their code in core CLISP, and we want to be able to (or let the user)
provide modules to extend CLISP at will (and even at runtime, with
dynamic loading).

And adding a new module should not require changes to core CLISP,
right? A user should be able to write some module, and let clisp-link
from the installed CLISP do it's magic.

Now assume a CLISP module needs (for example) access to some_function,
but core CLISP does not. The gnulib module the_module provides that
some_function on systems where it's not available. Should we add
the_module to core CLISP? I think no, because that would bloat core
CLISP (and we'd need special linker flags to actually have it in the
resulting binary). Thus we add it to the CLISP module, and
everything's fine.

Until we extend the CLISP module and it suddenly needs
another_function. Core CLISP happens to need this function, too. So
the gnulib module another_module which provides this function is
already included in CLISP. Now we could just use that and be done with
it.

Until we need another version (newer, older, using xalloc-die instead
of xalloc, ...) of it. Or another_module and the_module both depend on
a gnulib module lowlevel_thing. another_module only works with
lowlevel_thing from a year ago, but the_module needs a recent one.

My point is: gnulib is not designed to be something "shareable"
across projects (and core CLISP and a module is basically that: two
separate projects).

Thus IMO the correct approach at using gnulib is to have a gnulib
checkout for core CLISP, using only the gnulib modules needed by core
CLISP. And letting each CLISP module (which wants/needs to use gnulib)
maintain an own gnulib checkout with only the gnulib modules needed by
that particular CLISP module.

This adds some bloat when functionality overlaps (rawsock and
socket.d, and basic stuff like file IO), but probably only on "gnulib
intensive" platforms (windows?):

https://sourceforge.net/p/clisp/bugs/634/

Also I think complaining about a missing libgnu.so won't help. That's
just not the way gnulib is supposed to be used.



> what was the problem [updating gnulib for core CLISP]?

I'm not entierly sure. Makefile.devel tried to update (?) something
(configure?) for all modules first, but this failed for all
modules. IMO updating gnulib should - in the end - be no more effort
than running gnulib-tool --update (in the correct directories, that is
the top level directory and every module directory that has an own
gnulib checkout, we could put that into a script or Makefile.devel
then).


> Fine. This means that the change necessary for a release is actually
> quite small:
> [snip]
> Right?

Unfortunately it's not that easy: rawsock fails to build on Windows
(MinGW) because the gnulib code (from core CLISP) is too old and makes
a (now) false assumption about the internals of MinGW header files.

Thus, the necessary changes are:

1) Either update gnulib for core CLISP, or give rawsock its own gnulib
   (that's what I did and - due to the reasoning above - I'd argue
   for)

2) Remove "windows" specific code from rawsock.c: The typedef,
   including windows headers, the parts with #if defined(WIN32_NATIVE)

At this point it will compile, but has reduced functionality, because
gnulib has a (IMHO) design flaw: If there's no (for example) netdb.h,
then the corresponding gnulib module provides one. But it does not
#define HAVE_NETDB_H, thus our code would not use it (because of the
#if defined(HAVE_NETDB_H) conditional source parts).

Therefore we need to either remove the #if defined(..) stuff, or
(better) find a way to determine whether gnulib does provide a
replacement or not.

The first option is straightforward but will lead to issues with
platforms that are not supported by gnulib or where gnulib does not
provide a replacement (should we again target them).


> PLAN:
>
> -1- fix rawsock on windows and make a release (2.50)
> 2/3 *.d --> *.c rename
> 2/3 switch to autotools (dropping generated files)
> -4- update gnulib
> -5- your proposed regexp changes
> -6- release (3.0)


Due to all of the above discussion I think the first and most
important thing to do is to find a consensus on how we use gnulib, and
then update it (otherwise rawsock will not work).


> Okay, so you want to go the way of Emacs - the developers have to
> install autotools and the generated files are excluded from VCS.
> Fine.
> Let us do that after the release.
>
> Note, however, that you should use "hg mv" for configure.in -->
> configure.am transition and make changes to configure.am only after
> committing the "mv" operation (same for _all_ renaming).

Ok :)

Re: /bin/pwd

[Tomas H. <to...@lo...>]

Hi Sam,

Steingold <sd...@gn...> writes:
>> * Tomas Hlavaty <gb...@yb...> [2016-08-30 09:17:33 +0200]:
>> Sam Steingold <sd...@gn...> writes:
>>> running external programs without a full path is a security risk.
>>
>> What is the reasoning behind this assertion?
>
> * if clisp executes "pwd" and
> * you have, say, "~/bin" in your $PATH before "/bin" and
> * a malicious actor plants an executable named "pwd" into "~/bin", then
>   you will run that executable as yourself.

thanks for your reply.

Tomas

Re: /bin/pwd

[Jan S. <ha...@st...>]

On Aug 30 17:57:06, dan...@gm... wrote:
> I need these changes (removing the absolute paths) because I - running
> NixOS - don't have pwd, cat etc. in /bin/. That's the main reason for
> these commits.

You are suggesting to discard the standard, portable way of doing things
in order to accommodate one Frankenstein system.
Not that I have any say in this, but no way.

> If it is _really_ necessary to keep the absolute paths
> then I can keep these changes locally.

How about you locally make a /bin/pwd symlink
and leave things like they should be?

> > * if clisp executes "pwd" and you have, say, "~/bin" in your $PATH
> > * before "/bin" and * a malicious actor plants an executable named
> > * "pwd" into "~/bin", then you will run that executable as yourself.
> 
> ... I'm a bit annoyed by this:
> 
> What if a malicious actor plants an "exec modified_shell" into the
> shell's init file that rewrites all calls to /bin/pwd to a malicious
> binary? What if there's a rootkit running?

[snip rest of rant about how we are doomed anyway
if attacker can replace binaries]

> Even if we "secure" pwd and cat, what about: gcc, ranlib, ar, mv, cp,
> ln, make, ... ? Do we want to hardcode these paths, too?

I don't think that security concerns are the main issue here:
the point of calling /bin/pwd is not to "secure" pwd, but this:
if you want to know the current working directory in a script,
why would you call anything else but /bin/pwd?


BTW:

  $ uname -a
  SunOS fray1 5.11 11.3 sun4v sparc SUNW,SPARC-Enterprise-T5120
 
  $ find /bin/ /usr/bin/ /usr/xpg* -name pwd\*
  /bin/sparcv9/pwdx
  /bin/pwdx
  /bin/pwd
  /usr/bin/sparcv9/pwdx
  /usr/bin/pwdx
  /usr/bin/pwd

> The whole purpose behind things like $PATH is to be able to configure
> which binaries to use.

Not here. The purpose of calling pwd(1) in a script such as tests/*tst
is to get a result guaranteed by /bin/pwd to be what you expect.
What's there to "configure" about this?

> What if the user is a non-root user on some
> server, and the system /bin/pwd has a bug because of a wrong system
> time but the user has a working pwd in ~/bin ?(sounds unlikely? I've
> already been in that position ...)

Ah, another Frankenstein system we should accomodate
instead of doing the obvious, standard thing.

(BTW, how exactly would wrong system time
influence the behaviour of pwd(1)?)

> What if the user needs special versions of pwd, mv, cp and such
> because the sources live on a non-standard network filesystem that
> cannot be mounted, but can be accessed using these commands?
> (Unlikely, true, but we just don't know).

Hm, yet another Frankenstein. If you have a cp(1) that cannot cp
or a mv(1) that cannot mv, fix _that_ before writing any scripts.

> We could also think this further: We depend on libsigsegv. Why let the
> user specify where to find it when we can also download it directly
> during the build process and put it into a known location?

Because libsigsegv can be installed anywhere in the system,
unlike standard binaries like pwd(1).

	Jan

Re: pre-processing

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-30 18:10:12 +0200]:
>
>> * gctrigger is necessary for GCSAFETY -- keep it!
>
> Hm ... what about this:
>
> MAYGC(void, my_function_name, type1, param1, type2, param2) {
>   // code
> }

We already have LISPFUN which looks like that, so, I guess, it will be
okay - even though I would _much_ prefer the standard C syntax.

> Getting rid of all preprocessing would be nice because then we could
> use the implicit rules and dependency tracking of automake.

C module files are pre-processed, so I don't think pre-processing can go
away entirely.

>> * txt2c is for doc processing, I think we should move away from it
>
> Do I understand correctly that txt2c is mostly used to enable or
> disable parts of the docs depending on the configuration, as well as
> putting some data about the build and configuration into the docs
> (like whether it uses trivialmap memory or not)?

yes, exactly.

> This is what AC_CONFIG_FILES and its variable substitution is IMO for,
> though I'm not sure if it can replace txt2c completely (and in an
> elegant and easy to use way).

I don't think this is feasible or convenient.

>>  (what do other projects use?)

This is the key question.

txt2c processes these files:

* _clisp.c
https://sourceforge.net/p/clisp/mailman/message/23484750/
(also explained in its header)
looks like double pre-processing is inevitable.

* README*
--- should have no platform-dependent parts.

* man pages clisp.1, clisp.html &c
--- what do other projects use? e.g., does Emacs or sbcl or perl or
    python man pages differ on different platforms?


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://iris.org.il http://www.dhimmitude.org
http://truepeace.org http://ffii.org http://thereligionofpeace.com
Takeoffs are optional.  Landings are mandatory.

Re: pre-processing

[Daniel J. <dan...@gm...>]

> I am pretty sure we can assume C99 when building CLISP.

That's good :)

> * gctrigger is necessary for GCSAFETY -- keep it!

Hm ... what about this:

MAYGC(void, my_function_name, type1, param1, type2, param2) {
  // code
}

I'm pretty sure I could write a preprocessor macro that can turn the
above into the equivalent of what's currently produced by gctrigger.
(all it does is placing GCTRIGGER(param1, param2) in there,
depending on type1 and type2, right?)

Getting rid of all preprocessing would be nice because then we could
use the implicit rules and dependency tracking of automake.


> * txt2c is for doc processing, I think we should move away from it
>  (what do other projects use?)

Do I understand correctly that txt2c is mostly used to enable or
disable parts of the docs depending on the configuration, as well as
putting some data about the build and configuration into the docs
(like whether it uses trivialmap memory or not)?

This is what AC_CONFIG_FILES and its variable substitution is IMO for,
though I'm not sure if it can replace txt2c completely (and in an
elegant and easy to use way).


> I would like that to happen _after_ the release.

Sounds reasonable :)

Re: /bin/pwd

[Daniel J. <dan...@gm...>]

These little changes spawned quite a lot of discussion ...

I need these changes (removing the absolute paths) because I - running
NixOS - don't have pwd, cat etc. in /bin/. That's the main reason for
these commits. If it is _really_ necessary to keep the absolute paths
then I can keep these changes locally. Now I really don't want to
offend anyone, so please don't get upset by the following, but I like
being honest and ...


> * if clisp executes "pwd" and you have, say, "~/bin" in your $PATH
> * before "/bin" and * a malicious actor plants an executable named
> * "pwd" into "~/bin", then you will run that executable as yourself.

... I'm a bit annoyed by this:

What if a malicious actor plants an "exec modified_shell" into the
shell's init file that rewrites all calls to /bin/pwd to a malicious
binary?

What if there's a rootkit running? What if the shell is running within
a proot (usermode chroot) session that mounts a directory with
malicious binaries to /bin?

What if a malicious actor does this:
alias cd='some_command_involing_rm_rf_and_a_home_directory'

Even if we "secure" pwd and cat, what about: gcc, ranlib, ar, mv, cp,
ln, make, ... ? Do we want to hardcode these paths, too?


The point is: It is none of our business. If a malicious actor has
that much control over the users environment, then all hope is lost
eitherway. Moreover, we're talking here about the build system, and
not about software to counteract such a security breach (this wouldn't
make sense to run from the user environment eitherway).

The whole purpose behind things like $PATH is to be able to configure
which binaries to use. What if the user is a non-root user on some
server, and the system /bin/pwd has a bug because of a wrong system
time but the user has a working pwd in ~/bin ?(sounds unlikely? I've
already been in that position ...)

What if the user needs special versions of pwd, mv, cp and such
because the sources live on a non-standard network filesystem that
cannot be mounted, but can be accessed using these commands?
(Unlikely, true, but we just don't know).

The user should provide external dependencies. The build system tries
to find them, or let's the user otherwise provide the location of
these dependencies (for example by setting $PATH ..)

We could also think this further: We depend on libsigsegv. Why let the
user specify where to find it when we can also download it directly
during the build process and put it into a known location? Why not
download a libc of our choice? Or a compiler? ...


That said, all of this (except the /bin/cat in the test) will become
pointless because as soon as we switch to an autotools based build
system, because it will do the right thing anyway.


The discussion also seems to carry a bit much of emotion, so I hope I
don't make things worse, but I'd like to come back to my original
question:

> Why do we need the physical (not logical, i.e. without the
> symlinks) path, though?

Rephrasing: Why do we want to compare directories?

Re: status update

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-28 23:55:18 +0200]:
>
>> 15620::::Daniel Jour 2016-06-19 regexp: use autotools, gnulib, improve
>> buffer handling
>>
>> 0! This is 3 patches in one:
>
> Yes, this is too much for a single change. I was working on all three
> changes at the same time, which is how this huge commit came into
> being (sorry).

This is an absolute NO.
Each commit must reflect a single logical change.
It's hard, it requires discipline and focus, but this is the only way.

>> 1. Why are you replacing stack allocation with arbitrary limits?
>
> I don't? I'm switching the buffer size for the error message from
> BUFSIZ (which is an unrelated constant that could be easily too much
> for the stack) to another constant SAFE_ERROR_MESSAGE_LENGTH which we
> can define to a known "good" value (128 is a first start .. if there's
> an error message that's longer we can expand this, and consistently
> test whether that's too much on the stack or not).

BUFSIZ is a pretty standard constant for all string buffers.

> The other change is more important: With a carefully crafted regex
> expression one can currently crash (or potentially worse) CLISP,
> because the buffer for the matches can overflow the stack.

Let us revisit this issue at a later date.
I think the with_string_0 mechanism is good enough.
If disagree, you will have to argue for it to be changed pervasively
throughout CLISP.

>> 2. Is it really necessary to create a separate m4 directory for the
>>   single file gnulib-cache.m4? It's really ugly! (same for the
>>   rawsock change below).
>
> Yes, that's the directory where all the gnulib (m4 macros) should
> reside in, too. Running gnulib-tool --update in the regexp module
> directory populates that directory (as well as lib/).

This is why we don't run gnulib-tool in that directory!
We only ever run it in src.

> I think the current state (in which I commited this) is unfortunate,
> though: The gnulib files (in m4/ and lib/) should be put under (our)
> revision control, too. What do you think would be the best approach
> here?
> (gnulib has some discussion about this very issue:
> https://www.gnu.org/software/gnulib/manual/gnulib.html#VCS-Issues)

The gnulib file we import are already under our VCS in clisp/src/glm4
and clisp/src/gllib.

>> 15625:::tip:Daniel Jour 2016-08-23 rawsock: autotools build system,
>> own gnulib checkout
>>
>> Copying code from socked.d into rawsock.c is no good.
>
> Yes, this is a (dirty) work around: I was not able to update the
> gnulib code for core CLISP (thus socket.d).

what was the problem?

>> Also, you removed the configure script, so now people have to install
>> autoconf to build clisp.
>> Are you sure this is right?
>
> I removed it from the repository because it is a generated file
> now. It would be part of a source distribution (a release) though,
> thus only CLISP developers need to have autoconf/automake/etc.

Okay, so you want to go the way of Emacs - the developers have to
install autotools and the generated files are excluded from VCS.
Fine.
Let us do that after the release.

Note, however, that you should use "hg mv" for configure.in -->
configure.am transition and make changes to configure.am only after
committing the "mv" operation (same for _all_ renaming).

>> DIUC that the main change required to make rawsock work on windows
>> was the switch from rawsock_t to int?
>
> Basically, yes. gnulib is (or in part, will be) handling the windows
> specific code. rawsock is interfacing to POSIX/BSD sockets, gnulib is
> implementing them on windows.

Fine. This means that the change necessary for a release is actually
quite small:

--8<---------------cut here---------------start------------->8---
diff -r 2d1aedc0b550 modules/rawsock/rawsock.c
--- a/modules/rawsock/rawsock.c	Mon Aug 29 19:20:13 2016 -0400
+++ b/modules/rawsock/rawsock.c	Tue Aug 30 11:00:39 2016 -0400
@@ -66,7 +66,7 @@
 #if defined(HAVE_IFADDRS_H)
 # include <ifaddrs.h>
 #endif
-typedef SOCKET rawsock_t;
+typedef int rawsock_t;
 
 DEFMODULE(rawsock,"RAWSOCK")
 
--8<---------------cut here---------------end--------------->8---

Right?

>> please take a look at clisp/modules/berkeley-db/bdb.c:bdb_handle()
>> for getting the regex_t pointer out of the struct.
>
> Hm .. is this faster than the approach that I took? It saves a level
> of indirection ("one pointer"), right? Or is there something else
> wrong with the approach I took in regexp?

It's the same but it allows restarts (i.e., the user can supply a
different input if original argument is bad - instead of aborting the
whole thing).

In fact, you might want to model your approach on what I did in
modules/pcre instead of modules/berkeley-db.

However, this should be done _after_ the release.

PLAN:

-1- fix rawsock on windows and make a release (2.50)
2/3 *.d --> *.c rename
2/3 switch to autotools (dropping generated files)
-4- update gnulib
-5- your proposed regexp changes
-6- release (3.0)

Did I miss anything?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://think-israel.org http://camera.org
http://truepeace.org http://www.memritv.org http://dhimmi.org
Press any key to continue or any other key to quit.

Re: pre-processing

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-28 23:55:18 +0200]:
>
>> When did // comments go into the C standard?
>
> C99, "ANSI C" (C89/90) didn't have these yet (but I'd bet the major
> compilers wouldn't complain when not in -pedantic mode, didn't check
> though.)

I am pretty sure we can assume C99 when building CLISP.
This means that

* varbrace can be dropped (after deleting the "var" keyword)
* comment5 can be dropped (after converting the comments)
* ccmp2c is needed for new-clx, let it be for now
* ccpaux is only needed on SUNWspro - does it even exist still?
* deema is not needed on C99 (and C++11) (http://stackoverflow.com/q/33332819/850781)
* gctrigger is necessary for GCSAFETY -- keep it!
* txt2c is for doc processing, I think we should move away from it (what
  do other projects use?)

The bottom line is that some source pre-processing (specifically,
gctrigger) will _always_ be with us, so the transition to automake will
have to account for that.

The plan for now is to drop varbrace, comment5, ccpaux, deema and rename
all sources to *.c from *.d.

I would like that to happen _after_ the release.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://openvotingconsortium.org
http://islamexposedonline.com http://ffii.org http://www.memritv.org
Vegetarians eat Vegetables, Humanitarians are scary.

Re: WIDE_AUXI

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...> [2016-08-09 10:13:11 +0200]:
>
> Yes you can discard it.

done

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://palestinefacts.org http://www.dhimmitude.org
http://www.memritv.org http://memri.org http://dhimmi.org
Yeah, yeah, I love cats too... wanna trade recipes?

Re: status update

[Sam S. <sd...@gn...>]

> * Jan Stary <un...@fg...> [2016-08-30 11:10:34 +0200]:
>
> More importantly, /bin/pwd is a standardized UNIX binary,
> guaranteed to exist, with behaviour defined by POSIX
> - as opposed to "pwd", which can be a shell builtin
> (of whichever shell the user is running),
> or anything named "pwd" that happens to be in $PATH.

Excellent!
Indeed, the _functionality_ is specified:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pwd.html
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cat.html

Note, however, that /bin is not mentioned in
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html

I agree that the UNIX tradition enshrines /bin sufficiently so that we
need not worry that /bin/pwd or /bin/cat will ever surprise us:
https://en.wikipedia.org/wiki/Unix_filesystem
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
http://www.linfo.org/bin.html
http://unix.stackexchange.com/questions/5915/difference-between-bin-and-usr-bin
http://askubuntu.com/questions/138547/how-to-understand-the-ubuntu-file-system-layout

The bottom line is that there is no compelling case to drop the full
path, so let us keep it for the time being.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://iris.org.il http://jihadwatch.org
http://truepeace.org http://islamexposedonline.com http://palestinefacts.org
C combines the power of assembler with the portability of assembler.

Re: /bin/pwd

[Sam S. <sd...@gn...>]

Hi,

> * Tomas Hlavaty <gb...@yb...> [2016-08-30 09:17:33 +0200]:
> Sam Steingold <sd...@gn...> writes:
>> running external programs without a full path is a security risk.
>
> What is the reasoning behind this assertion?

* if clisp executes "pwd" and
* you have, say, "~/bin" in your $PATH before "/bin" and
* a malicious actor plants an executable named "pwd" into "~/bin", then
  you will run that executable as yourself.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://honestreporting.com http://think-israel.org
http://iris.org.il http://thereligionofpeace.com http://islamexposedonline.com
Abandon all hope, all ye who press Enter.

Re: status update

[Jan S. <ha...@st...>]

> 15613::::Daniel Jour 2016-04-30 clisp-link.in: Replace /bin/pwd with calls to pwd (for NixOS)
> 15617::::Daniel Jour 2016-05-18 Don't call cat by absolute path

> > pwd is also a shell built-in, so full path is necessary.
> 
> Hm, I understand why pwd may give (in case of symbolic links) a
> different result as a non-builtin pwd. Why do we need the physical
> (not logical, i.e. without the symlinks) path, though?

That's just part of the issue.
For example, on OpenBSD, using ksh(1):

  $ cd /tmp
  $ mkdir foo
  $ ln -s foo bar
  $ cd bar
  $ pwd
  /tmp/bar
  $ /bin/pwd
  /tmp/foo

More importantly, /bin/pwd is a standardized UNIX binary,
guaranteed to exist, with behaviour defined by POSIX
- as opposed to "pwd", which can be a shell builtin
(of whichever shell the user is running),
or anything named "pwd" that happens to be in $PATH.

So make your mind about whether you want the symlinks resolved or not,
and call either "/bin/pwd -P" or "/bin/pwd -L".
(Because the default behaviour without options can also differ.)
http://man.openbsd.org/OpenBSD-current/man1/pwd.1

> As for /bin/pwd ... this is a bad idea.
> /bin (the directory) is about to die

Stop smoking that shit.

/bin has been around for decades and will continue to be,
whatever any linux distro du jour gets to its head.

> (ok, that's a bit drastic, I'm reffering to the "usr merge"
> here), and there may be more than one pwd on a single system

So use the standard one, obviously.

> (this is the main reason for this change, because it directly affects me.
> This could be fixed downstream by the currently few affected distributions,
> too. But in the future this might affect every linux distribution that
> uses systemd.)

UNIX is not this or that "affected Linux distribution".
http://man.openbsd.org/OpenBSD-current/man7/hier.7

> Same goes for /bin/cat

Exactly.

> There might be more than one cat, and all of
> them might be in a different location than /bin.

Except /bin/cat will always be there, with POSIX-defined behaviour.
So use that, obviously.

> Thus it's better to let the user (or the user's configured
> environment) choose which cat to use.

Quite the contrary: this is the reason to use the standard one.

> Perhaps we could use (if it's still needed then) an autoconf macro to
> determine the "correct" cat and pwd? (Using $CAT and $PWD then, so the
> user could change these.)

Yeah right. Let the user rewrite PWD.


On Aug 29 19:32:28, pip...@ic... wrote:
> I think what Daniel is suggesting here goes farther than the current goals
> of the usr-move camp (see [1] and [2]). Traditionally, /bin and /usr (thus /usr/bin)
> could live on different partitions and be mounted at different points in time. I
> believe defenders of the usr-move idea will argue that there’s no good use case
> for that anymore,

On OpenBSD, for example, the programs in /bin are statically compiled,
and therefore do not depend the libraries or the linker.
That's why you can use them to e.g. repair your system in single-user mode,
with /usr/* botched. Or use them in scripts without further assumptions.

> so that /usr can just be assumed to be available whenever /bin
> is assumed to be available.

Again, that's not the issue here.

> That does not mean that /bin/cp and the like go the
> way of the dodo but rather that they might be symlinks to /usr/bin/cp, so that as
> a package maintainer you no longer need to spend time thinking about what has
> to go in /bin and what can go in /usr/bin instead.

How much time do you need to spend thinking about the following?

$ ldd /bin/ls
/bin/ls:
  Start            End              Type Open Ref GrpRef Name
  000001301d32b000 000001301d778000 dlib 1    0   0      /bin/ls

$ ldd /usr/bin/diff
/usr/bin/diff:
  Start            End              Type Open Ref GrpRef Name
  00001a3559f00000 00001a355a309000 exe  1    0   0      /usr/bin/diff
  00001a3773834000 00001a3773cfd000 rlib 0    1   0      /usr/lib/libc.so.88.0
  00001a3760300000 00001a3760300000 rtld 0    1   0      /usr/libexec/ld.so


On Aug 30 09:17:33, to...@lo... wrote:
> Bruno Haible <br...@cl...> writes:
> > Differences between /bin/<prog> and <prog> in general:
> >
> >   * You can be sure that /bin/<prog> exists; you don't need to handle
> >     the case that PATH has been set in such a way that <prog> is not found.
> 
> counterexample:
> 
> $ ls -al /bin
> total 8
> drwxr-xr-x   2 root           root     4096 2016-08-25 09:44 .
> drwxr-xr-x  17 root           root     4096 2016-05-29 00:28 ..
> lrwxrwxrwx   1 root           root       63 2016-08-25 09:44 sh -> /nix/store/9zv8ph14qa9x685ig6agxy9yzxcapfar-bash-4.3-p42/bin/sh
> $

That's not a counterexample: /bin/sh exists, as it always should;
but depending on PATH, "sh" might not be found.

> Any dependency on external programs comes with many assumptions and no
> guaranties.

Except the standardized /bin/pwd etc,
which is precisely the reason to use those, and not some others.

> For example, using /bin/<prog> harcodes the assumption
> about FHS, among others.

Yes. Much like using printf(3) hardcodes
the assumption that you have a standard C library.

> > The only good argument against /bin/<prog> that I can see is that some
> > modern distros, like GNU GuixSD, construct PATH based on symbolic
> > links.  But I would expect them to have a mechanism to simulate a /bin
> > directory in some way.
> 
> Yes.  They don't simulate the /bin directory.  They patch away the
> hardcoded paths and construct the environment in such a way, that the
> program uses the right dependencies.  Or, they replace the hardcoded
> path with the correct path of the dependency.
> 
> So from the point of those modern distros, I think it is slightly better
> not to hardcode the FHS assumption so that they do not have to patch the
> sources.

Something small in me dies every time I see a _language_interpreter_
being considered "from the point of modern distros".

	Jan

Re: /bin/pwd

[Tomas H. <to...@lo...>]

Hi,

Bruno Haible <br...@cl...> writes:
> Differences between /bin/<prog> and <prog> in general:
>
>   * You can be sure that /bin/<prog> exists; you don't need to handle
>     the case that PATH has been set in such a way that <prog> is not found.

counterexample:

$ ls -al /bin
total 8
drwxr-xr-x   2 root           root     4096 2016-08-25 09:44 .
drwxr-xr-x  17 root           root     4096 2016-05-29 00:28 ..
lrwxrwxrwx   1 root           root       63 2016-08-25 09:44 sh -> /nix/store/9zv8ph14qa9x685ig6agxy9yzxcapfar-bash-4.3-p42/bin/sh
$

This is on NixOS so your assertion is valid only for systems that follow
certain convention,
e.g. <https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard>.

Any dependency on external programs comes with many assumptions and no
guaranties.  For example, using /bin/<prog> harcodes the assumption
about FHS, among others.

>   * PATH is under user control. If you use <prog> you need to handle
>     the case that <prog> is not executable, a dangling link, or it could
>     be slowed down on an NFS volume etc.

Using /bin/<prog> has exactly the same problems as well as harcoding FHS
assumption.

> The only good argument against /bin/<prog> that I can see is that some
> modern distros, like GNU GuixSD, construct PATH based on symbolic
> links.  But I would expect them to have a mechanism to simulate a /bin
> directory in some way.

Yes.  They don't simulate the /bin directory.  They patch away the
hardcoded paths and construct the environment in such a way, that the
program uses the right dependencies.  Or, they replace the hardcoded
path with the correct path of the dependency.

So from the point of those modern distros, I think it is slightly better
not to hardcode the FHS assumption so that they do not have to patch the
sources.  However, even if the path stays hardcoded, it is a solved
problem (I have clisp running here).

Sam Steingold <sd...@gn...> writes:
> running external programs without a full path is a security risk.

What is the reasoning behind this assertion?

Tomas

Re: /bin/pwd

[Bruno H. <br...@cl...>]

Sam wrote:
> > * Daniel Jour <qna...@tz...> [2016-08-28 23:55:18 +0200]:
> >
> >> pwd is also a shell built-in, so full path is necessary.
> >
> > Hm, I understand why pwd may give (in case of symbolic links) a
> > different result as a non-builtin pwd. Why do we need the physical
> > (not logical, i.e. without the symlinks) path, though?
> >
> > As for /bin/pwd ... this is a bad idea. /bin (the directory) is about
> > to die (ok, that's a bit drastic, I'm reffering to the "usr merge"
> > here), and there may be more than one pwd on a single system (this is
> > the main reason for this change, because it directly affects me. This
> > could be fixed downstream by the currently few affected distributions,
> > too. But in the future this might affect every linux distribution that
> > uses systemd.)
> 
> this is news to me.
> "/bin/cp" going away will break so much stuff that I doubt that anyone
> will seriously contemplate this.
> 
> any unix experts here?

Differences between /bin/<prog> and <prog> in general:

  * You can be sure that /bin/<prog> exists; you don't need to handle
    the case that PATH has been set in such a way that <prog> is not found.

  * PATH is under user control. If you use <prog> you need to handle
    the case that <prog> is not executable, a dangling link, or it could
    be slowed down on an NFS volume etc.

Differences between /bin/pwd and pwd in particular:

  * pwd being a shell built-in, it takes care not to canonicalize the
    directory name. If we want to canonicalize the directory name, e.g.
    to test whether two directories are equal
      A_abs=`cd "$A" && /bin/pwd`
      B_abs=`cd "$B" && /bin/pwd`
      test "$A_abs" = "$B_abs"
    we can only use /bin/pwd.

The only good argument against /bin/<prog> that I can see is that some
modern distros, like GNU GuixSD, construct PATH based on symbolic links.
But I would expect them to have a mechanism to simulate a /bin directory
in some way.

Bruno

Re: status update

[Elias P. <pip...@ic...>]

> On 29 Aug 2016, at 19:17, Sam Steingold <sd...@gn...> wrote:
> 
>> * Daniel Jour <qna...@tz...> [2016-08-28 23:55:18 +0200]:
>> 
>>> pwd is also a shell built-in, so full path is necessary.
>> 
>> Hm, I understand why pwd may give (in case of symbolic links) a
>> different result as a non-builtin pwd. Why do we need the physical
>> (not logical, i.e. without the symlinks) path, though?
>> 
>> As for /bin/pwd ... this is a bad idea. /bin (the directory) is about
>> to die (ok, that's a bit drastic, I'm reffering to the "usr merge"
>> here), and there may be more than one pwd on a single system (this is
>> the main reason for this change, because it directly affects me. This
>> could be fixed downstream by the currently few affected distributions,
>> too. But in the future this might affect every linux distribution that
>> uses systemd.)
> 
> this is news to me.
> "/bin/cp" going away will break so much stuff that I doubt that anyone
> will seriously contemplate this.

I think what Daniel is suggesting here goes farther than the current goals
of the usr-move camp (see [1] and [2]). Traditionally, /bin and /usr (thus /usr/bin)
could live on different partitions and be mounted at different points in time. I
believe defenders of the usr-move idea will argue that there’s no good use case
for that anymore, so that /usr can just be assumed to be available whenever /bin
is assumed to be available. That does not mean that /bin/cp and the like go the
way of the dodo but rather that they might be symlinks to /usr/bin/cp, so that as
a package maintainer you no longer need to spend time thinking about what has
to go in /bin and what can go in /usr/bin instead. As a typical user you would not
notice any difference.

That said, I chimed in here to save the unit experts some typing, not because
I consider myself one (I don’t).


Elias

[1] http://0pointer.net/blog/projects/the-usr-merge.html
[2] https://fedoraproject.org/wiki/Features/UsrMove

Re: status update

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-28 23:55:18 +0200]:
>
>> pwd is also a shell built-in, so full path is necessary.
>
> Hm, I understand why pwd may give (in case of symbolic links) a
> different result as a non-builtin pwd. Why do we need the physical
> (not logical, i.e. without the symlinks) path, though?
>
> As for /bin/pwd ... this is a bad idea. /bin (the directory) is about
> to die (ok, that's a bit drastic, I'm reffering to the "usr merge"
> here), and there may be more than one pwd on a single system (this is
> the main reason for this change, because it directly affects me. This
> could be fixed downstream by the currently few affected distributions,
> too. But in the future this might affect every linux distribution that
> uses systemd.)

this is news to me.
"/bin/cp" going away will break so much stuff that I doubt that anyone
will seriously contemplate this.

any unix experts here?
Bruno?

> Same goes for /bin/cat: There might be more than one cat, and all of
> them might be in a different location than /bin. Thus it's better to
> let the user (or the user's configured environment) choose which cat
> to use.

running external programs without a full path is a security risk.

> Perhaps we could use (if it's still needed then) an autoconf macro to
> determine the "correct" cat and pwd? (Using $CAT and $PWD then, so the
> user could change these.)

I don't think this is a good idea for "cat" (used once in the test
suite), but for pwd - maybe.


>
>
>> 15624::::Daniel Jour 2016-06-22 Remove comment5 utility, and any
>> remaining non-C comments
>>
>> Nope.
>> Each line with separate /* .. */ is ugly.
>> We need to use either blocks or //.
>
> Hm, indeed ...
>
>
>> When did // comments go into the C standard?
>
> C99, "ANSI C" (C89/90) didn't have these yet (but I'd bet the major
> compilers wouldn't complain when not in -pedantic mode, didn't check
> though.)
>
>
>> Also, I think this should be done together with removing all
>> pre-processing and renaming all *.d files to *.c.
>
>
> This would also extremely simplify the Makefile.am file for
> automake. What's the best base (revision) to make such a change on?
>
>
>
>> 15620::::Daniel Jour 2016-06-19 regexp: use autotools, gnulib, improve
>> buffer handling
>>
>> 0! This is 3 patches in one:
>
> Yes, this is too much for a single change. I was working on all three
> changes at the same time, which is how this huge commit came into
> being (sorry).
>
>> 1. Why are you replacing stack allocation with arbitrary limits?
>
> I don't? I'm switching the buffer size for the error message from
> BUFSIZ (which is an unrelated constant that could be easily too much
> for the stack) to another constant SAFE_ERROR_MESSAGE_LENGTH which we
> can define to a known "good" value (128 is a first start .. if there's
> an error message that's longer we can expand this, and consistently
> test whether that's too much on the stack or not).
>
> The other change is more important: With a carefully crafted regex
> expression one can currently crash (or potentially worse) CLISP,
> because the buffer for the matches can overflow the stack. I think
> this might be an issue for e.g. web applications that pass a regex
> expression such that a - potentially malicious - user can modify
> it. As application developer I wouldn't expect an regex of some (arbitrary,
> stack frame dependent) length to be able to crush my whole application.
>
> Therefore I changed it so that a small buffer is still allocated on
> the stack (because of the speed benefit), but larger buffers get
> allocated using dynamic memory allocation (which, in case of a
> failure, raises a condition).
>
> It's not waterproof though: A large number of matches (from a
> carefully crafted expression) could still cause the LISP stack to
> overflow. I don't know how to prevent that, though (except for
> enforcing some maximum).
>
>
>> 2. Is it really necessary to create a separate m4 directory for the
>>   single file gnulib-cache.m4? It's really ugly! (same for the
>>   rawsock change below).
>
> Yes, that's the directory where all the gnulib (m4 macros) should
> reside in, too. Running gnulib-tool --update in the regexp module
> directory populates that directory (as well as lib/).
>
> I think the current state (in which I commited this) is unfortunate,
> though: The gnulib files (in m4/ and lib/) should be put under (our)
> revision control, too. What do you think would be the best approach
> here?
> (gnulib has some discussion about this very issue:
> https://www.gnu.org/software/gnulib/manual/gnulib.html#VCS-Issues)
>
>
>
>> 15625:::tip:Daniel Jour 2016-08-23 rawsock: autotools build system,
>> own gnulib checkout
>>
>> Copying code from socked.d into rawsock.c is no good.
>
> Yes, this is a (dirty) work around: I was not able to update the
> gnulib code for core CLISP (thus socket.d).  I was planing to revert
> that as soon as core CLISP also uses updated gnulib code.
>
> I'm a bit worried about these dependencies (between the modules -
> rawsock needing OS - and the rawsock module and the socket code from
> core CLISP) though. Though this is IMO not relevant for now.
>
>
>> Also, you removed the configure script, so now people have to install
>> autoconf to build clisp.
>> Are you sure this is right?
>
> I removed it from the repository because it is a generated file
> now. It would be part of a source distribution (a release) though,
> thus only CLISP developers need to have autoconf/automake/etc.
>
>
>> DIUC that the main change required to make rawsock work on windows
>> was the switch from rawsock_t to int?
>
> Basically, yes. gnulib is (or in part, will be) handling the windows
> specific code. rawsock is interfacing to POSIX/BSD sockets, gnulib is
> implementing them on windows.
>
> But I noticed that this commit still contains (printf) debugging and
> other oddities. I'll fix that ASAP.
>
>
>
>> what does "wip" in "wip-autotools-export" stand for?
>
> work in progress. This is the state of switching to autotools at the
> end of the coding period. It's not finished or useable yet. Which is
> why ...
>
>> the change to built.d seems incomplete.
>
> ... a lot of the changes in that commit are indeed still incomplete.
>
>
>> I need to understand what you are doing before importing anything.
>> The best way would be if you made an isolated change
>> (e.g., I don't see why you had to touch built.d).
>
> I'll try to isolate the changes needed to get an autotools based build
> system from integrating the configuration into autoconf macros. This
> should reduce the size of each change. I don't know how fast I'm able
> to provide this atm, though.
>
>
>
>> please take a look at clisp/modules/berkeley-db/bdb.c:bdb_handle()
>> for getting the regex_t pointer out of the struct.
>
> Hm .. is this faster than the approach that I took? It saves a level
> of indirection ("one pointer"), right? Or is there something else
> wrong with the approach I took in regexp?
>
> ------------------------------------------------------------------------------
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://camera.org http://dhimmi.org
http://www.dhimmitude.org http://thereligionofpeace.com
Illiterate?  Write today, for free help!

clisp-cvs Digest, Vol 72, Issue 2

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: Use __CYGWIN__ instead of __CYGWIN32__ to detect
      Cygwin (cli...@li...)
   2. clisp: clispload.lsp --> clispload.lisp
      (cli...@li...)
   3. clisp: rename modprep.lisp test files to better correspond to
      th... (cli...@li...)
   4. clisp: avoid the clang -Wgnu-designator warning
      (cli...@li...)
   5. clisp: fix last patch (cli...@li...)
   6. clisp: avoid -Wwrite-strings warning
      (cli...@li...)
   7. clisp: * utils/modprep.lisp (output-all): Bind all global
      variab... (cli...@li...)
   8. clisp: (output-all): make sure that the file name is printed
      on ... (cli...@li...)
   9. clisp:
      (custom:*suppress-similar-constant-redefinition-warning*)...
      (cli...@li...)
  10. clisp: oops... (cli...@li...)
  11. clisp: regenerated (cli...@li...)
  12. clisp: set
      custom:*suppress-similar-constant-redefinition-warnin...
      (cli...@li...)
  13. clisp: Fix bug#684: modprep handling of quotation mark in
      single... (cli...@li...)
  14. clisp: Fix bug#677 logical pathnames and letter case gone
      wrong (cli...@li...)
  15. clisp: * src/makemake.in (check-script) [darwin]: disable
      nohup (cli...@li...)
  16. clisp: adapted for MacOSX idiosyncrasies
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Sun, 28 Aug 2016 21:31:02 +0000
From: cli...@li...
Subject: clisp: Use __CYGWIN__ instead of __CYGWIN32__ to detect
	Cygwin
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/344339845531
changeset: 15638:34433984553100c3911190f536f787710bf7065a
user:      Ken Brown <kb...@co...>
date:      2015-03-05 11:35:30 -0500
description:
Use __CYGWIN__ instead of __CYGWIN32__ to detect Cygwin

__CYGWIN32__ is deprecated and, more importantly, is not defined on
64-bit Cygwin.

diffstat:

 src/ChangeLog       |  7 +++++++
 src/ari80386.d      |  2 +-
 src/ari80386.msvc.c |  2 +-
 src/asmi386.h       |  4 ++--
 src/asmi386.hh      |  4 ++--
 src/lispbibl.d      |  8 ++++----
 src/sp80386.d       |  2 +-
 src/sp80386.msvc.c  |  2 +-
 8 files changed, 19 insertions(+), 12 deletions(-)



------------------------------

Message: 2
Date: Sun, 28 Aug 2016 21:31:03 +0000
From: cli...@li...
Subject: clisp: clispload.lsp --> clispload.lisp
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/23bc9b1f6571
changeset: 15639:23bc9b1f6571c77976396c8f54792ecfb2f3a889
user:      Sam Steingold <sd...@gn...>
date:      2016-08-26 17:42:26 -0400
description:
clispload.lsp --> clispload.lisp

diffstat:

 utils/clispload.lisp |  245 +++++++++++++++++++++++++++++++++++++++++++++++++++
 utils/clispload.lsp  |  245 ---------------------------------------------------
 2 files changed, 245 insertions(+), 245 deletions(-)



------------------------------

Message: 3
Date: Sun, 28 Aug 2016 21:31:04 +0000
From: cli...@li...
Subject: clisp: rename modprep.lisp test files to better correspond to
	th...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/3ccf2365a5a0
changeset: 15640:3ccf2365a5a0fbb355bedda44ef1e05ada0afee0
user:      Sam Steingold <sd...@gn...>
date:      2016-08-28 00:44:54 -0400
description:
rename modprep.lisp test files to better correspond to their names in modules

diffstat:

 utils/modprep.lisp    |    4 +
 utils/modpreptest.c   |   29 ++++++
 utils/modpreptest.in  |   29 ------
 utils/modpreptest.m.c |  209 ++++++++++++++++++++++++++++++++++++++++++++++++++
 utils/modpreptest.out |  209 --------------------------------------------------
 5 files changed, 242 insertions(+), 238 deletions(-)



------------------------------

Message: 4
Date: Sun, 28 Aug 2016 21:31:06 +0000
From: cli...@li...
Subject: clisp: avoid the clang -Wgnu-designator warning
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/ba853d8a4faa
changeset: 15641:ba853d8a4faa2ffb88fc90143ab6b96cafe9d98a
user:      Sam Steingold <sd...@gn...>
date:      2016-08-28 17:30:43 -0400
description:
avoid the clang -Wgnu-designator warning

* src/lispbibl.d (as_object, as_chart): use the new {.one_o=???}
syntax instead of GNU old-style field designator extension {one_o:???}
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Designated-Inits.html

diffstat:

 src/ChangeLog  |   7 +++++++
 src/lispbibl.d |  20 ++++++++++----------
 2 files changed, 17 insertions(+), 10 deletions(-)



------------------------------

Message: 5
Date: Mon, 29 Aug 2016 04:01:49 +0000
From: cli...@li...
Subject: clisp: fix last patch
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/bcb890855a9c
changeset: 15642:bcb890855a9ce3f7362754dc604aa90b7b3483c5
user:      Sam Steingold <sd...@po...>
date:      2016-08-28 18:09:50 -0400
description:
fix last patch

diffstat:

 src/lispbibl.d |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



------------------------------

Message: 6
Date: Mon, 29 Aug 2016 04:01:50 +0000
From: cli...@li...
Subject: clisp: avoid -Wwrite-strings warning
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a5d6627283e6
changeset: 15643:a5d6627283e66f6f20a890acd6819ef42e09ddb2
user:      Sam Steingold <sd...@po...>
date:      2016-08-28 18:15:31 -0400
description:
avoid -Wwrite-strings warning

* src/genclisph.d (emit_export_declaration, struct typecode_entry):
use `const' to avoid the warning:
deprecated conversion from string constant to char* [-Wwrite-strings]

diffstat:

 src/ChangeLog   |  6 ++++++
 src/genclisph.d |  4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)



------------------------------

Message: 7
Date: Mon, 29 Aug 2016 04:01:52 +0000
From: cli...@li...
Subject: clisp: * utils/modprep.lisp (output-all): Bind all global
	variab...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/c87d5ad371d3
changeset: 15644:c87d5ad371d3ef7e974bee9ba7b6f4f4c7fe4621
user:      Sam Steingold <sd...@po...>
date:      2016-08-28 23:55:33 -0400
description:
* utils/modprep.lisp (output-all): Bind all global variables in appropriate functions to allow loading into the same lisp session

diffstat:

 src/ChangeLog      |   5 ++++
 utils/modprep.lisp |  58 ++++++++++++++++++++++++++++++++---------------------
 2 files changed, 40 insertions(+), 23 deletions(-)



------------------------------

Message: 8
Date: Mon, 29 Aug 2016 04:01:53 +0000
From: cli...@li...
Subject: clisp: (output-all): make sure that the file name is printed
	on ...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/39fcd9e6bbb1
changeset: 15645:39fcd9e6bbb176ca5c9b7cdab9a718dc7324b796
user:      Sam Steingold <sd...@po...>
date:      2016-08-28 23:56:52 -0400
description:
(output-all): make sure that the file name is printed on #line 1 without #P

diffstat:

 src/ChangeLog      |  4 +++-
 utils/modprep.lisp |  2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)



------------------------------

Message: 9
Date: Mon, 29 Aug 2016 04:01:54 +0000
From: cli...@li...
Subject: clisp:
	(custom:*suppress-similar-constant-redefinition-warning*)...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/bba3fa7d1c74
changeset: 15646:bba3fa7d1c740c140caad9bc2501864691add13b
user:      Sam Steingold <sd...@po...>
date:      2016-08-28 23:58:56 -0400
description:
(custom:*suppress-similar-constant-redefinition-warning*) [:compile-toplevel]: set to T to avoid the warnings on reload

diffstat:

 src/ChangeLog      |  2 ++
 utils/modprep.lisp |  3 +++
 2 files changed, 5 insertions(+), 0 deletions(-)



------------------------------

Message: 10
Date: Mon, 29 Aug 2016 04:01:56 +0000
From: cli...@li...
Subject: clisp: oops...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/58505bf3d646
changeset: 15647:58505bf3d646d43e94a95d3c36b0bfeabe61fd0e
user:      Sam Steingold <sd...@po...>
date:      2016-08-29 00:01:18 -0400
description:
oops...

diffstat:

 utils/modprep.lisp |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)



------------------------------

Message: 11
Date: Mon, 29 Aug 2016 04:01:57 +0000
From: cli...@li...
Subject: clisp: regenerated
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/8a95063830d8
changeset: 15648:8a95063830d806040bb02e9e263f3f3db9d2181b
user:      Sam Steingold <sd...@po...>
date:      2016-08-29 00:01:33 -0400
description:
regenerated

diffstat:

 utils/modpreptest.m.c |  202 ++++++++++++++++++++++++++-----------------------
 1 files changed, 107 insertions(+), 95 deletions(-)



------------------------------

Message: 12
Date: Mon, 29 Aug 2016 04:15:26 +0000
From: cli...@li...
Subject: clisp: set
	custom:*suppress-similar-constant-redefinition-warnin...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/82cb358f41b1
changeset: 15649:82cb358f41b10c81d0ac1edf23de6eca38c27635
user:      Sam Steingold <sd...@gn...>
date:      2016-08-29 00:13:21 -0400
description:
set custom:*suppress-similar-constant-redefinition-warning* in all situations

diffstat:

 utils/modprep.lisp |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



------------------------------

Message: 13
Date: Mon, 29 Aug 2016 04:15:27 +0000
From: cli...@li...
Subject: clisp: Fix bug#684: modprep handling of quotation mark in
	single...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/32cc5e8d4609
changeset: 15650:32cc5e8d4609b91389c7697c3483ad1a38921766
user:      Sam Steingold <sd...@gn...>
date:      2016-08-29 00:15:16 -0400
description:
Fix bug#684: modprep handling of quotation mark in single line comment

* utils/modprep.lisp (lexical-analysis): handle // comments

diffstat:

 src/ChangeLog         |   5 +++++
 utils/modprep.lisp    |   4 ++++
 utils/modpreptest.c   |  11 ++++++++++-
 utils/modpreptest.m.c |  19 ++++++++++++++-----
 4 files changed, 33 insertions(+), 6 deletions(-)



------------------------------

Message: 14
Date: Mon, 29 Aug 2016 17:10:04 +0000
From: cli...@li...
Subject: clisp: Fix bug#677 logical pathnames and letter case gone
	wrong
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/114a28a4d42b
changeset: 15651:114a28a4d42bde057c034b173ee6d18467329017
user:      Sam Steingold <sd...@gn...>
date:      2016-08-29 11:09:54 -0400
description:
Fix bug#677 logical pathnames and letter case gone wrong

* src/compiler.lisp (compile-file-pathname-helper): when output is
supplied and is physical, translate input from logical before merge

diffstat:

 src/ChangeLog     |  6 ++++++
 src/compiler.lisp |  5 ++++-
 tests/path.tst    |  9 +++++++++
 3 files changed, 19 insertions(+), 1 deletions(-)



------------------------------

Message: 15
Date: Mon, 29 Aug 2016 17:10:06 +0000
From: cli...@li...
Subject: clisp: * src/makemake.in (check-script) [darwin]: disable
	nohup
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1f40f265be1c
changeset: 15652:1f40f265be1c2e14617635c8f39380acf1e8edb5
user:      Sam Steingold <sd...@gn...>
date:      2016-08-29 11:22:19 -0400
description:
* src/makemake.in (check-script) [darwin]: disable nohup

http://stackoverflow.com/questions/29112446/nohup-doesnt-work-with-os-x-yosmite-get-error-cant-detach-from-console-no-s
http://stackoverflow.com/questions/23898623/nohup-cant-detach-from-console

diffstat:

 src/ChangeLog   |   6 ++++++
 src/makemake.in |  10 +++++++++-
 2 files changed, 15 insertions(+), 1 deletions(-)



------------------------------

Message: 16
Date: Mon, 29 Aug 2016 17:10:07 +0000
From: cli...@li...
Subject: clisp: adapted for MacOSX idiosyncrasies
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a30681acd895
changeset: 15653:a30681acd895892f16ce3da138aba48a1435d4a4
user:      Sam Steingold <sd...@gn...>
date:      2016-08-29 11:35:17 -0400
description:
adapted for MacOSX idiosyncrasies

ECONNREFUSED is 61, not 111
sometimes signal EADDRNOTAVAIL (line on Win32) instead
sometimes succeed instead...

diffstat:

 tests/socket.tst |  15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)



------------------------------

------------------------------------------------------------------------------


------------------------------

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 72, Issue 2
****************************************

Re: status update

[Daniel J. <dan...@gm...>]

> pwd is also a shell built-in, so full path is necessary.

Hm, I understand why pwd may give (in case of symbolic links) a
different result as a non-builtin pwd. Why do we need the physical
(not logical, i.e. without the symlinks) path, though?

As for /bin/pwd ... this is a bad idea. /bin (the directory) is about
to die (ok, that's a bit drastic, I'm reffering to the "usr merge"
here), and there may be more than one pwd on a single system (this is
the main reason for this change, because it directly affects me. This
could be fixed downstream by the currently few affected distributions,
too. But in the future this might affect every linux distribution that
uses systemd.)

Same goes for /bin/cat: There might be more than one cat, and all of
them might be in a different location than /bin. Thus it's better to
let the user (or the user's configured environment) choose which cat
to use.

Perhaps we could use (if it's still needed then) an autoconf macro to
determine the "correct" cat and pwd? (Using $CAT and $PWD then, so the
user could change these.)



> 15624::::Daniel Jour 2016-06-22 Remove comment5 utility, and any remaining non-C comments
>
> Nope.
> Each line with separate /* .. */ is ugly.
> We need to use either blocks or //.

Hm, indeed ...


> When did // comments go into the C standard?

C99, "ANSI C" (C89/90) didn't have these yet (but I'd bet the major
compilers wouldn't complain when not in -pedantic mode, didn't check
though.)


> Also, I think this should be done together with removing all
> pre-processing and renaming all *.d files to *.c.


This would also extremely simplify the Makefile.am file for
automake. What's the best base (revision) to make such a change on?



> 15620::::Daniel Jour 2016-06-19 regexp: use autotools, gnulib, improve buffer handling
>
> 0! This is 3 patches in one:

Yes, this is too much for a single change. I was working on all three
changes at the same time, which is how this huge commit came into
being (sorry).

> 1. Why are you replacing stack allocation with arbitrary limits?

I don't? I'm switching the buffer size for the error message from
BUFSIZ (which is an unrelated constant that could be easily too much
for the stack) to another constant SAFE_ERROR_MESSAGE_LENGTH which we
can define to a known "good" value (128 is a first start .. if there's
an error message that's longer we can expand this, and consistently
test whether that's too much on the stack or not).

The other change is more important: With a carefully crafted regex
expression one can currently crash (or potentially worse) CLISP,
because the buffer for the matches can overflow the stack. I think
this might be an issue for e.g. web applications that pass a regex
expression such that a - potentially malicious - user can modify
it. As application developer I wouldn't expect an regex of some (arbitrary,
stack frame dependent) length to be able to crush my whole application.

Therefore I changed it so that a small buffer is still allocated on
the stack (because of the speed benefit), but larger buffers get
allocated using dynamic memory allocation (which, in case of a
failure, raises a condition).

It's not waterproof though: A large number of matches (from a
carefully crafted expression) could still cause the LISP stack to
overflow. I don't know how to prevent that, though (except for
enforcing some maximum).


> 2. Is it really necessary to create a separate m4 directory for the
>   single file gnulib-cache.m4? It's really ugly! (same for the
>   rawsock change below).

Yes, that's the directory where all the gnulib (m4 macros) should
reside in, too. Running gnulib-tool --update in the regexp module
directory populates that directory (as well as lib/).

I think the current state (in which I commited this) is unfortunate,
though: The gnulib files (in m4/ and lib/) should be put under (our)
revision control, too. What do you think would be the best approach
here?
(gnulib has some discussion about this very issue:
https://www.gnu.org/software/gnulib/manual/gnulib.html#VCS-Issues)



> 15625:::tip:Daniel Jour 2016-08-23 rawsock: autotools build system, own gnulib checkout
>
> Copying code from socked.d into rawsock.c is no good.

Yes, this is a (dirty) work around: I was not able to update the
gnulib code for core CLISP (thus socket.d).  I was planing to revert
that as soon as core CLISP also uses updated gnulib code.

I'm a bit worried about these dependencies (between the modules -
rawsock needing OS - and the rawsock module and the socket code from
core CLISP) though. Though this is IMO not relevant for now.


> Also, you removed the configure script, so now people have to install
> autoconf to build clisp.
> Are you sure this is right?

I removed it from the repository because it is a generated file
now. It would be part of a source distribution (a release) though,
thus only CLISP developers need to have autoconf/automake/etc.


> DIUC that the main change required to make rawsock work on windows
> was the switch from rawsock_t to int?

Basically, yes. gnulib is (or in part, will be) handling the windows
specific code. rawsock is interfacing to POSIX/BSD sockets, gnulib is
implementing them on windows.

But I noticed that this commit still contains (printf) debugging and
other oddities. I'll fix that ASAP.



> what does "wip" in "wip-autotools-export" stand for?

work in progress. This is the state of switching to autotools at the
end of the coding period. It's not finished or useable yet. Which is
why ...

> the change to built.d seems incomplete.

... a lot of the changes in that commit are indeed still incomplete.


> I need to understand what you are doing before importing anything.
> The best way would be if you made an isolated change
> (e.g., I don't see why you had to touch built.d).

I'll try to isolate the changes needed to get an autotools based build
system from integrating the configuration into autoconf macros. This
should reduce the size of each change. I don't know how fast I'm able
to provide this atm, though.



> please take a look at clisp/modules/berkeley-db/bdb.c:bdb_handle()
> for getting the regex_t pointer out of the struct.

Hm .. is this faster than the approach that I took? It saves a level
of indirection ("one pointer"), right? Or is there something else
wrong with the approach I took in regexp?

clisp-cvs Digest, Vol 72, Issue 2

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: fix the 2012-04-27 patch c88260c2da71 (symlink to
      directo... (cli...@li...)
   2. clisp: (check_copy_method): fix STACK depth handling
      (cli...@li...)
   3. clisp: (PCRE:PCRE-EXEC): fix a GC-safety bug
      (cli...@li...)
   4. clisp: fix GC-safety bugs in copy_one_file
      (cli...@li...)
   5. clisp: avoid gcc compilation warnings
      (cli...@li...)
   6. clisp: avoid test failure with g++
      (cli...@li...)
   7. clisp: (VALUE1_EXTRA) [!value1_register]: do not define
      (cli...@li...)
   8. clisp: Update asdf to version 3.1.7
      (cli...@li...)
   9. clisp: Fix locale related errors when testing getdate
      (cli...@li...)
  10. clisp: Disable TRIVIALMAP_MEMORY and SINGLEMAP_MEMORY on
      NetBSD (cli...@li...)
  11. clisp: reorder (cli...@li...)
  12. clisp: * src/unix.d [UNIX_CYGWIN32]: Work around namespace
      pollu... (cli...@li...)
  13. clisp: * src/lispbibl.d: Use LINUX_NOEXEC_HEAPCODES on 32-bit
      Cy... (cli...@li...)
  14. clisp: * src/m4/signal.m4: Remove obsolete Cygwin-specific
      code (cli...@li...)
  15. clisp: * src/lispbibl.d (ULONGLONG): Avoid conflict with w32
      typ... (cli...@li...)
  16. clisp: Fix dynamic loading on Cygwin
      (cli...@li...)
  17. clisp: (XCFLAGS) [XCC_GCC]: treat gcc 5 & 6 like 3 & 4 (fixes
      bu... (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Fri, 12 Aug 2016 22:41:11 +0000
From: cli...@li...
Subject: clisp: fix the 2012-04-27 patch c88260c2da71 (symlink to
	directo...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2857eae38681
changeset: 15621:2857eae38681edf905c722b80143eae6d6a5d86d
user:      Sam Steingold <sd...@po...>
date:      2016-08-11 21:39:33 -0400
description:
fix the 2012-04-27 patch c88260c2da71 (symlink to directory handling)

* src/pathname.d (delete_directory): fix rmdir() failure handling

diffstat:

 src/ChangeLog  |  4 ++++
 src/pathname.d |  2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)



------------------------------

Message: 2
Date: Fri, 12 Aug 2016 22:41:14 +0000
From: cli...@li...
Subject: clisp: (check_copy_method): fix STACK depth handling
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b5f00441f807
changeset: 15622:b5f00441f807d9bfcd90140de414ac332dff9220
user:      Sam Steingold <sd...@po...>
date:      2016-08-12 18:26:07 -0400
description:
(check_copy_method): fix STACK depth handling

diffstat:

 modules/syscalls/calls.c  |  11 +++++------
 modules/syscalls/test.tst |  37 +++++++++++++++++++++++++++++++++----
 src/ChangeLog             |   4 ++++
 3 files changed, 42 insertions(+), 10 deletions(-)



------------------------------

Message: 3
Date: Fri, 12 Aug 2016 22:41:16 +0000
From: cli...@li...
Subject: clisp: (PCRE:PCRE-EXEC): fix a GC-safety bug
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e219233849af
changeset: 15623:e219233849af1ff83731f9a0765a8bfe471b51d1
user:      Sam Steingold <sd...@po...>
date:      2016-08-12 18:30:25 -0400
description:
(PCRE:PCRE-EXEC): fix a GC-safety bug

diffstat:

 modules/pcre/cpcre.c  |  8 ++++----
 modules/pcre/test.tst |  2 +-
 src/ChangeLog         |  6 +++++-
 3 files changed, 10 insertions(+), 6 deletions(-)



------------------------------

Message: 4
Date: Sun, 14 Aug 2016 04:16:53 +0000
From: cli...@li...
Subject: clisp: fix GC-safety bugs in copy_one_file
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/46aa3992f3a0
changeset: 15624:46aa3992f3a0d9fd64c666f03b93b2bc5b27db9f
user:      Sam Steingold <sd...@po...>
date:      2016-08-14 00:09:43 -0400
description:
fix GC-safety bugs in copy_one_file

* modules/syscalls/calls.c (hardlink_file_o): add
(copy_one_file): fix GC-safety bugs

diffstat:

 modules/syscalls/calls.c  |  44 ++++++++++++++++++++++++--------------------
 modules/syscalls/test.tst |  15 ++++++++++-----
 src/ChangeLog             |   5 +++++
 3 files changed, 39 insertions(+), 25 deletions(-)



------------------------------

Message: 5
Date: Sun, 14 Aug 2016 04:16:54 +0000
From: cli...@li...
Subject: clisp: avoid gcc compilation warnings
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a9746f412ab8
changeset: 15625:a9746f412ab88b64b563c1e133ffd4f7110e5dc5
user:      Sam Steingold <sd...@po...>
date:      2016-08-14 00:11:17 -0400
description:
avoid gcc compilation warnings

diffstat:

 modules/syscalls/calls.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)



------------------------------

Message: 6
Date: Sun, 14 Aug 2016 04:16:55 +0000
From: cli...@li...
Subject: clisp: avoid test failure with g++
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b1477e46b3c9
changeset: 15626:b1477e46b3c99971f89b6920be3701c61ed7045c
user:      Sam Steingold <sd...@po...>
date:      2016-08-14 00:13:57 -0400
description:
avoid test failure with g++

diffstat:

 modules/syscalls/test.tst |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)



------------------------------

Message: 7
Date: Fri, 26 Aug 2016 19:04:05 +0000
From: cli...@li...
Subject: clisp: (VALUE1_EXTRA) [!value1_register]: do not define
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/44eed0fb007a
changeset: 15627:44eed0fb007a3404de6e63f8987ea22e4d67c808
user:      Sam Steingold <sd...@po...>
date:      2016-08-26 13:47:00 -0400
description:
(VALUE1_EXTRA) [!value1_register]: do not define

This fixes patch#93dee6a014b2bc75ed9e6f7bb6f6929fb97a68bc (2008-01-13)
as discussed in https://sourceforge.net/p/clisp/mailman/message/35061096/

diffstat:

 src/ChangeLog  |  6 ++++++
 src/lispbibl.d |  3 +--
 2 files changed, 7 insertions(+), 2 deletions(-)



------------------------------

Message: 8
Date: Fri, 26 Aug 2016 19:04:07 +0000
From: cli...@li...
Subject: clisp: Update asdf to version 3.1.7
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1429e42cb2a8
changeset: 15628:1429e42cb2a81709f2e10dafda67d392fd418b6c
user:      Daniel Jour <dan...@gm...>
date:      2016-05-16 01:50:23 +0200
description:
Update asdf to version 3.1.7

* modules/asdf/asdf.lisp: Update to 3.1.7
* modules/asdf/asdf.xml: Update asdf module description

diffstat:

 modules/asdf/asdf.lisp |  6121 +++++++++++++++++++++++++++++++----------------
 modules/asdf/asdf.xml  |     9 +-
 src/ChangeLog          |     6 +
 3 files changed, 4062 insertions(+), 2074 deletions(-)



------------------------------

Message: 9
Date: Fri, 26 Aug 2016 19:04:08 +0000
From: cli...@li...
Subject: clisp: Fix locale related errors when testing getdate
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/924519c6b452
changeset: 15629:924519c6b452a641e9e62c6b65417b48116b80d3
user:      Daniel Jour <dan...@gm...>
date:      2016-05-18 12:23:45 +0200
description:
Fix locale related errors when testing getdate

diffstat:

 modules/syscalls/test.tst |  22 ++++++++++++++++++----
 1 files changed, 18 insertions(+), 4 deletions(-)



------------------------------

Message: 10
Date: Fri, 26 Aug 2016 19:04:09 +0000
From: cli...@li...
Subject: clisp: Disable TRIVIALMAP_MEMORY and SINGLEMAP_MEMORY on
	NetBSD
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1c61a0872d35
changeset: 15630:1c61a0872d35c2a19dfdaaeb673f7b70365c30e2
user:      Daniel Jour <dan...@gm...>
date:      2016-06-09 02:46:06 +0200
description:
Disable TRIVIALMAP_MEMORY and SINGLEMAP_MEMORY on NetBSD

CLISP uses MAP_FIXED when calling mmap, but the requested addresses are not
within any mappable range on NetBSD, thus it fails with ENOMEM.

diffstat:

 src/ChangeLog  |   6 ++++++
 src/lispbibl.d |  20 ++++++++++++++++----
 2 files changed, 22 insertions(+), 4 deletions(-)



------------------------------

Message: 11
Date: Fri, 26 Aug 2016 19:04:11 +0000
From: cli...@li...
Subject: clisp: reorder
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/bf16ec104ed4
changeset: 15631:bf16ec104ed4e9985787971af47b42e27ff87a9b
user:      Sam Steingold <sd...@po...>
date:      2016-08-26 14:07:33 -0400
description:
reorder

diffstat:

 src/ChangeLog |  25 +++++++++++++------------
 1 files changed, 13 insertions(+), 12 deletions(-)



------------------------------

Message: 12
Date: Sun, 28 Aug 2016 21:30:53 +0000
From: cli...@li...
Subject: clisp: * src/unix.d [UNIX_CYGWIN32]: Work around namespace
	pollu...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a4a0a2c83f0d
changeset: 15632:a4a0a2c83f0d1f48a6c21b97ae554c4743fc02b9
user:      Ken Brown <kb...@co...>
date:      2015-03-04 18:11:34 -0500
description:
* src/unix.d [UNIX_CYGWIN32]: Work around namespace pollution in w32 headers

"Handle" is used in a w32 prototype, interfering with our definition
of it as a macro.

diffstat:

 src/ChangeLog |  7 +++++++
 src/unix.d    |  3 +++
 2 files changed, 10 insertions(+), 0 deletions(-)



------------------------------

Message: 13
Date: Sun, 28 Aug 2016 21:30:55 +0000
From: cli...@li...
Subject: clisp: * src/lispbibl.d: Use LINUX_NOEXEC_HEAPCODES on 32-bit
	Cy...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/4f89513266a5
changeset: 15633:4f89513266a5827048f39574adf4fa56ca0147e1
user:      Ken Brown <kb...@co...>
date:      2015-03-04 22:05:35 -0500
description:
* src/lispbibl.d: Use LINUX_NOEXEC_HEAPCODES on 32-bit Cygwin

The heap on Cygwin is now in high memory, so STANDARD_HEAPCODES will
no longer work.

diffstat:

 src/ChangeLog  |  6 ++++++
 src/lispbibl.d |  2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)



------------------------------

Message: 14
Date: Sun, 28 Aug 2016 21:30:56 +0000
From: cli...@li...
Subject: clisp: * src/m4/signal.m4: Remove obsolete Cygwin-specific
	code
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a4ff7f8b180c
changeset: 15634:a4ff7f8b180c96a6842088591986320d5ec6e552
user:      Ken Brown <kb...@co...>
date:      2015-03-05 11:28:06 -0500
description:
* src/m4/signal.m4: Remove obsolete Cygwin-specific code

diffstat:

 src/ChangeLog    |   4 ++++
 src/m4/signal.m4 |  25 -------------------------
 2 files changed, 4 insertions(+), 25 deletions(-)



------------------------------

Message: 15
Date: Sun, 28 Aug 2016 21:30:58 +0000
From: cli...@li...
Subject: clisp: * src/lispbibl.d (ULONGLONG): Avoid conflict with w32
	typ...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2334c6034ea3
changeset: 15635:2334c6034ea3505d26eac32b676f972db401aaee
user:      Ken Brown <kb...@co...>
date:      2015-03-05 12:30:28 -0500
description:
* src/lispbibl.d (ULONGLONG): Avoid conflict with w32 typedef

on 64-bit Cygwin

diffstat:

 src/ChangeLog  |  7 ++++++-
 src/lispbibl.d |  4 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)



------------------------------

Message: 16
Date: Sun, 28 Aug 2016 21:30:59 +0000
From: cli...@li...
Subject: clisp: Fix dynamic loading on Cygwin
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/69da1aa5ee51
changeset: 15636:69da1aa5ee51ebdd695122ea208353c969ec1766
user:      Ken Brown <kb...@co...>
date:      2015-03-18 11:34:21 -0400
description:
Fix dynamic loading on Cygwin

* src/genclisph.d [UNIX_CYGWIN32]: Fix syntax error in lisp.def.
* src/makemake.in (archive_cmds): Fix definition on Cygwin.
(lisp.def): Add "hostent_to_lisp" to lisp.def on Cygwin.
(clisp-link): Use absolute path to lisp.def.

diffstat:

 src/ChangeLog   |   8 ++++++++
 src/genclisph.d |   6 ++++++
 src/makemake.in |  20 +++++++++++++++++---
 3 files changed, 31 insertions(+), 3 deletions(-)



------------------------------

Message: 17
Date: Sun, 28 Aug 2016 21:31:01 +0000
From: cli...@li...
Subject: clisp: (XCFLAGS) [XCC_GCC]: treat gcc 5 & 6 like 3 & 4 (fixes
	bu...
To: cli...@li...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e0b4ecbc8c4a
changeset: 15637:e0b4ecbc8c4adc70d3b47a81e7492727d19c07ad
user:      Sam Steingold <sd...@po...>
date:      2016-08-26 16:38:39 -0400
description:
(XCFLAGS) [XCC_GCC]: treat gcc 5 & 6 like 3 & 4 (fixes bug#686)

diffstat:

 src/ChangeLog   |   5 +++++
 src/makemake.in |  12 ++++++------
 2 files changed, 11 insertions(+), 6 deletions(-)



------------------------------

------------------------------------------------------------------------------


------------------------------

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 72, Issue 2
****************************************

Re: status update

[Sam S. <sd...@gn...>]

> * Sam Steingold <fq...@ta...> [2016-08-26 14:49:08 -0400]:
>
> 15621::::Daniel Jour 2016-06-20 regexp: wrap foreign pointer in REGEX structure

please take a look at clisp/modules/berkeley-db/bdb.c:bdb_handle() for
getting the regex_t pointer out of the struct.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://www.dhimmitude.org http://www.memritv.org
http://dhimmi.org http://americancensorship.org http://mideasttruth.com
If you're constantly being mistreated, you're cooperating with the
treatment.

Re: status update

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-25 21:35:57 +0200]:
>
>> - Merging in your changes: where is your repo, how can I access your
>>  patchsets &c.
>
> Here's my fork of the main repo (I can currently not provide a link
> listing only my commits due to the limited internet access):
>
> https://sourceforge.net/u/musteresel/clisp/ci/default/tree/
>
> This contains the changes that are currently useable. One thing I need
> to check is whether I included the files related to gnulib (I think I
> didn't, just the cache from which they can be reproduced using
> gnulib-tool).

15613::::Daniel Jour 2016-04-30 clisp-link.in: Replace /bin/pwd with calls to pwd (for NixOS)

pwd is also a shell built-in, so full path is necessary.

15614::::Daniel Jour 2016-04-30 modules/bindings/glibc/linux.lisp: Replace non-standard header include

Fine (I committed an equivalent patch a couple of weeks ago).
This is out of scope though.

15615::::Daniel Jour 2016-05-01 lispbibl.d: don't treat value1 extra if it's not in a register

The metadata (ChangeLog, log summary) is lacking.
I merged this patch with the appropriate metadata.
This is also out of scope though.

15616::::Daniel Jour 2016-05-16 Update asdf to version 3.1.7

Accepted.

15617::::Daniel Jour 2016-05-18 Don't call cat by absolute path

why?

15618::::Daniel Jour 2016-05-18 Fix locale related errors when testing getdate

Accepted.

15619::::Daniel Jour 2016-06-09 Disable TRIVIALMAP_MEMORY and SINGLEMAP_MEMORY on NetBSD

Accepted.

15620::::Daniel Jour 2016-06-19 regexp: use autotools, gnulib, improve buffer handling

0! This is 3 patches in one:
   (a) autotools
   (b) alloca-->static
   (c) do not compute matches when a boolean is returned
1. Why are you replacing stack allocation with arbitrary limits?
2. Is it really necessary to create a separate m4 directory for the
   single file gnulib-cache.m4? It's really ugly! (same for the rawsock
   change below).

15621::::Daniel Jour 2016-06-20 regexp: wrap foreign pointer in REGEX structure
15622::::Daniel Jour 2016-06-21 regexp: Don't return a list when there are many matches
15623::::Daniel Jour 2016-06-21 regexp: Allow selection of return type also for match

these do not apply cleanly without the above.


15624::::Daniel Jour 2016-06-22 Remove comment5 utility, and any remaining non-C comments

Nope.
Each line with separate /* .. */ is ugly.
We need to use either blocks or //.
When did // comments go into the C standard?
Also, I think this should be done together with removing all
pre-processing and renaming all *.d files to *.c.

15625:::tip:Daniel Jour 2016-08-23 rawsock: autotools build system, own gnulib checkout

Copying code from socked.d into rawsock.c is no good.
Also, you removed the configure script, so now people have to install
autoconf to build clisp.
Are you sure this is right?

DIUC that the main change required to make rawsock work on windows was
the switch from rawsock_t to int?



> Next, the changes towards an autotools based build (and configuration)
> system:
>
> https://gist.github.com/musteresel/ee87db0a79e4eb22cfdd2d85afe45bff

what does "wip" in "wip-autotools-export" stand for?
the change to built.d seems incomplete.

> This is a squashed commit (I made some changes back and forth which
> are not that usefull in a commit history) of the current WIP state,
> exported using hg export (thus should be importable using hg import on
> the above repository).

I need to understand what you are doing before importing anything.
The best way would be if you made an isolated change
(e.g., I don't see why you had to touch built.d).


> Then, the libmagic module:
>
> https://gist.github.com/musteresel/6c3b9eeea10818c7e8f6d6672b030401
>
> It's still missing tests and does not cover the complete functionality
> provided by the libmagic on my system.

Okay, by the time you finish it you will probably have write access to
the tree ;-)

>> The upshot is that we need a link to your code.
>> This is urgent.
>
> Sorry for the delay, does the above help?

Yes, thanks.

>> - Making a release. How much effort will you be able to dedicate to
>>  CLISP during the school year (your studies are, of course, the
>>  priority)?
>
> In September probably almost none (exams). Starting Mid-October I'd
> estimate about 10hrs/week, though could also be more ...

Okay, so let us talk then if you are still interested.


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://palestinefacts.org http://jihadwatch.org
http://dhimmi.org http://think-israel.org http://honestreporting.com
When arguing with the wife, think: do you want to be right or happy?

Re: status update

[Daniel J. <dan...@gm...>]

> - Merging in your changes: where is your repo, how can I access your
>  patchsets &c.

Here's my fork of the main repo (I can currently not provide a link
listing only my commits due to the limited internet access):

https://sourceforge.net/u/musteresel/clisp/ci/default/tree/

This contains the changes that are currently useable. One thing I need
to check is whether I included the files related to gnulib (I think I
didn't, just the cache from which they can be reproduced using
gnulib-tool).

Next, the changes towards an autotools based build (and configuration)
system:

https://gist.github.com/musteresel/ee87db0a79e4eb22cfdd2d85afe45bff

This is a squashed commit (I made some changes back and forth which
are not that usefull in a commit history) of the current WIP state,
exported using hg export (thus should be importable using hg import on
the above repository).


Then, the libmagic module:

https://gist.github.com/musteresel/6c3b9eeea10818c7e8f6d6672b030401

It's still missing tests and does not cover the complete functionality
provided by the libmagic on my system.


> The upshot is that we need a link to your code.
> This is urgent.

Sorry for the delay, does the above help?

(A note regarding my limited internet access: This is very
unfortunate, and completely unexpected: My provider -simyo- merged
with/was sold to another company -blau- , which resulted in me being
switched to a different (mobile) network which apparently has a very
weak signal strength or is overloaded.)


> - Making a release. How much effort will you be able to dedicate to
>  CLISP during the school year (your studies are, of course, the
>  priority)?

In September probably almost none (exams). Starting Mid-October I'd
estimate about 10hrs/week, though could also be more (studies start
again but on the other hand then both of my kids are taken care of at
a daycare center; this means a lot more free time.). Next exams are
then around January/February.

Re: status update

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-23 20:50:08 +0200]:
>
> Ok, here comes the final GSoC status report.

Please follow the guidelines in
https://developers.google.com/open-source/gsoc/help/work-product
The upshot is that we need a link to your code.
This is urgent.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://honestreporting.com http://truepeace.org
http://iris.org.il http://camera.org http://openvotingconsortium.org
Professionalism is being dispassionate about your work.

Re: status update

[Sam S. <sd...@gn...>]

> * Daniel Jour <qna...@tz...> [2016-08-23 20:50:08 +0200]:
>
> Ok, here comes the final GSoC status report. Unfortunately, I did not
> reach the goal of working (building and passing tests) code on the
> major platforms.

Too bad.

Now we need to map out the next steps:

- Merging in your changes: where is your repo, how can I access your
  patchsets &c.

- Making a release. How much effort will you be able to dedicate to
  CLISP during the school year (your studies are, of course, the
  priority)?

> I had a lot of fun working on CLISP, and intend to do so in the
> future. Thank you all a lot for your help throughout this summer! :)

You are welcome!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://thereligionofpeace.com http://memri.org
http://jihadwatch.org http://dhimmi.org http://americancensorship.org
Don't use force -- get a bigger hammer.