Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.lisp > #32758 > unrolled thread

Buffer Overflow in LISP

Back to article view | Back to comp.lang.lisp

Contents

  Buffer Overflow in LISP yara.huss.113@gmail.com - 2019-04-25 03:52 -0700
    Re: Buffer Overflow in LISP shcv@sdf.org - 2019-04-25 09:21 -0400
    Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-04-25 15:21 +0200
      Re: Buffer Overflow in LISP Barry Margolin <barmar@alum.mit.edu> - 2019-04-25 11:04 -0400
        Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-04-25 19:22 +0200
          Re: Buffer Overflow in LISP Spiros Bousbouras <spibou@gmail.com> - 2019-04-28 08:34 +0000
            Re: Buffer Overflow in LISP Barry Margolin <barmar@alum.mit.edu> - 2019-04-29 12:31 -0400
          Re: Buffer Overflow in LISP a.daniel.eliason@gmail.com - 2019-05-23 08:35 -0700
            Re: Buffer Overflow in LISP Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-23 17:02 +0000
              Re: Buffer Overflow in LISP Stefan Monnier <monnier@iro.umontreal.ca> - 2019-05-30 15:50 -0400
            Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-23 19:30 +0200
              Re: Buffer Overflow in LISP taruss@google.com - 2019-05-24 10:40 -0700
                Re: Buffer Overflow in LISP Paul Rubin <no.email@nospam.invalid> - 2019-05-24 10:45 -0700
                  Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-24 23:27 +0200
                    [OT] was: Buffer Overflow in LISP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-24 22:46 +0100
                      Re: [OT] was: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-25 01:00 +0200
                      Re: [OT] was: Buffer Overflow in LISP Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-24 23:46 +0000
                        Re: [OT] was: Buffer Overflow in LISP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-25 01:35 +0100
                    Re: Buffer Overflow in LISP Jason Cornez <jcornez@ravenpack.com> - 2019-05-29 16:10 +0200
                      Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-29 20:25 +0200
        Re: Buffer Overflow in LISP Vladimir Sedach <vsedach@oneofus.la> - 2019-09-22 21:26 -0700
          Re: Buffer Overflow in LISP Barry Margolin <barmar@alum.mit.edu> - 2019-09-23 00:45 -0400

Page 1 of 2  [1] 2  Next page →

#32758 — Buffer Overflow in LISP

Does the LISP language eliminate the buffer overflow attack problem? 

[toc] | [next] | [standalone]

#32759

LISP is a pretty big family of languages and implementations, but in
general it's abstracted away from the actual memory usage, and protects
against things like buffer overflows.

It probably isn't impossible to write low-level unsafe code in some
implementations that give you access to it though.

[toc] | [prev] | [next] | [standalone]

#32760

yara.huss.113@gmail.com writes:

> Does the LISP language eliminate the buffer overflow attack problem?

This is not a question of language, strictly speaking.

By this I mean that both the ANSI Common Lisp Language Standard and the ISO C
Language Standard forbid buffer overflows, just like they forbid reading
uninitialized variables, etc.

But the way they forbid them is by specifying that the effect of such
actions are "implementation dependent" in the case of CL, or "undefined"
in the case of C.  Which practically means in both case, that it's up to
the implementation to decide what happens.

Notably, note that the C standard allows implementation to have run-time
handling of errors.

Furthermore in the case of CL, there's specified a SAFETY optimization
level, that let  you give an indication to the implementation on how
"safe" you want it the generated code to be, from 0 to 3.  Code compiled
with safety level 3 is called "safe code" (duh!), and has some
properties, but fundamentally, this doesn't change much. Spefically, it
doesn't impose the implementations to check bounds anymore than with
unsafe code.


So, both in the case of CL and of C, it's up to the implementation to
determine when, and if, bound checks are performed, and what would be
the consequences of an unbound access.

Now, it happens, for some strange social reasons, that the writers of
Common Lisp implementations will usually add run-time check, which will
signal run-time errors, and let the programmer handle them, while the
writers of C implementations will usually not include run-time checks,
and will blindly execute buffer overflows (unless the operating system
detects an invalid (unmapped) access and sends a SIGSEG or SIGBUS
signal).

But there's absolutely no reason why they should do that, from the
language specification point of view.


That said, one could conceive of a programming language that would
specify that invalid memory accesses be prevented in an implementation
independent way.

For example the programming language LSE (Langage Symbolic
d'Enseignement) specifies that using an invalid indice will produce a
run-time error, which will lead to the interruption of the program.
When running in an interactive environment, the user will then be able
to debug it (inspect the variables, modify them) and either stop or
continue the execution.  There is no uncertainty: this error detection
in LSE doesn't depend on the implementation, all LSE implementations
must detect those errors.


In conclusion, concerning Common Lisp, implementations will in general
detect out-of-bound accesses (and other errors), at run-time, notably
when the SAFETY optimization level is not 0; and some implementations
can also detect those error at compilation-time!


If you are concerned by buffer overflow errors, you should choose an
implementation that does detect such errors, and specify the compilation
options so it effectly does detect them.

In CL:

(declaim (optimize (safety 3) (debug 3) (speed 0) (space 0) (compilation-speed 0)))


In C, you could use gcc version 8, with the following options:

    gcc \
        -fsanitize=address \
        -fsanitize=null \
        -fsanitize=bounds \
        -fsanitize=vla-bound \
        -fsanitize=object-size \
        -fsanitize=unreachable \
        -fsanitize=shift \
        -fsanitize=shift-exponent \
        -fsanitize=shift-base \
        -fsanitize=integer-divide-by-zero \
        -fsanitize=signed-integer-overflow \
        -fsanitize=float-divide-by-zero \
        -fsanitize=float-cast-overflow \
        -fsanitize=nonnull-attribute \
        -fsanitize=returns-nonnull-attribute \
        -fsanitize=bool \
        -fsanitize=enum \
        -fsanitize-address-use-after-scope \
        -fsanitize-undefined-trap-on-error \
        -fstack-protector-all \
        -fstack-check \
        \
        -o pgm.o pgm.c


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#32761

In article <m2a7gez0d0.fsf@despina.home>,
 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote:

> Now, it happens, for some strange social reasons, that the writers of
> Common Lisp implementations will usually add run-time check, which will
> signal run-time errors, and let the programmer handle them, while the
> writers of C implementations will usually not include run-time checks,
> and will blindly execute buffer overflows (unless the operating system
> detects an invalid (unmapped) access and sends a SIGSEG or SIGBUS
> signal).
> 
> But there's absolutely no reason why they should do that, from the
> language specification point of view.

It's not just "social" reasons, but historical reasons. The languages 
were designed for writing different types of applications, and that 
context governed the philosophy around error handling.

C was created for writing an operating system. Efficiency is extremely 
important, so adding bounds checks to every memory access would impose 
an unacceptable performance penalty. Lisp, on the other hand, was 
designed for higher-level AI applications, where the overall complexity 
of the algorithms made concerns about low-level memory efficiency less 
significant. And when they did realize that performance was an issue, 
Lisp researchers developed special hardware (Lisp machines) that 
mitigated the performance problems invoked by their philosophy.

C's data model also makes it hard to implement these checks efficiently. 
Lisp doesn't provide a pointer data type, its standard data types 
abstract away the low-level memory model. 

But Patrick's point about Lisp "safety" sitting is quite relevant. 
Programmers generally expect Lisp to do type checking all over the 
place, but if you put it into unsafe mode, this can be bypassed. If you 
have a function like this:

(defun f (cons)
  (setf (car cons) 1))

and compile it in unsafe mode, you could call it like:

(f 12345)

It's expecting the argument to be a cons (which would likely be 
implemented by passing a pointer to the memory holding the two cells). 
If you pass it an integer, it might end up using that number as a 
pointer, so write 1 into memory location 12345. Boom!

And in unsafe mode, there's no guarantee that AREF will check that the 
index is actually within the array.

It's possible to implement C in a way similar to Lisp, but you get a 
performance impact. It was actually done when a C compiler was written 
for the Symbolics Lisp machines; C pointers were not just memory 
addresses as in traditional systems, but a pair containing a Lisp array 
and offset. malloc() essentially translated into MAKE-ARRAY + CONS, and 
dereferencing a pointer was AREF. C structures were also implemented 
this way. Lisp Machines didn't have "unsafe" mode (although there were 
low-level system primitives that allow direct memory access, since Lisp 
was used to implement the OS), so the bounds checks in arrays couldn't 
be bypassed.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#32763

Barry Margolin <barmar@alum.mit.edu> writes:

> In article <m2a7gez0d0.fsf@despina.home>,
>  "Pascal J. Bourguignon" <pjb@informatimago.com> wrote:
>
>> Now, it happens, for some strange social reasons, that the writers of
>> Common Lisp implementations will usually add run-time check, which will
>> signal run-time errors, and let the programmer handle them, while the
>> writers of C implementations will usually not include run-time checks,
>> and will blindly execute buffer overflows (unless the operating system
>> detects an invalid (unmapped) access and sends a SIGSEG or SIGBUS
>> signal).
>> 
>> But there's absolutely no reason why they should do that, from the
>> language specification point of view.
>
> It's not just "social" reasons, but historical reasons. The languages 
> were designed for writing different types of applications, and that 
> context governed the philosophy around error handling.
>
> C was created for writing an operating system. Efficiency is extremely 
> important, so adding bounds checks to every memory access would impose 
> an unacceptable performance penalty.

On the other hand, ensuring that the OS doesn't crash, or doesn't leak
security holes WAS NOT important, since UNIx was essentially a
single-user operating system on a small mini-computer.  Nowadays, unix
runs computers mostly for single-user computers (phones, tablets,
workstations), and very rarely for multiple users on big-iron.

But the key word is "WAS".  Nowadays, it's very important that even a
kernel be safe, and the hardware is fast enough to spend half the time
checking we're not computing bullshit.

Nowadays, we have the -fsafety arguments to gcc…


> Lisp, on the other hand, was 
> designed for higher-level AI applications, where the overall complexity 
> of the algorithms made concerns about low-level memory efficiency less 
> significant. And when they did realize that performance was an issue, 
> Lisp researchers developed special hardware (Lisp machines) that 
> mitigated the performance problems invoked by their philosophy.
>
> C's data model also makes it hard to implement these checks
> efficiently.

Who cares, when we have pipelined Intel processors?


> Lisp doesn't provide a pointer data type, its standard data types 
> abstract away the low-level memory model. 
>
> But Patrick's point about Lisp "safety" sitting is quite relevant. 
> Programmers generally expect Lisp to do type checking all over the 
> place, but if you put it into unsafe mode, this can be bypassed. If you 
> have a function like this:
>
> (defun f (cons)
>   (setf (car cons) 1))
>
> and compile it in unsafe mode, you could call it like:
>
> (f 12345)
>
> It's expecting the argument to be a cons (which would likely be 
> implemented by passing a pointer to the memory holding the two cells). 
> If you pass it an integer, it might end up using that number as a 
> pointer, so write 1 into memory location 12345. Boom!
>
> And in unsafe mode, there's no guarantee that AREF will check that the 
> index is actually within the array.
>
> It's possible to implement C in a way similar to Lisp, but you get a 
> performance impact. It was actually done when a C compiler was written 
> for the Symbolics Lisp machines; C pointers were not just memory 
> addresses as in traditional systems, but a pair containing a Lisp array 
> and offset. malloc() essentially translated into MAKE-ARRAY + CONS, and 
> dereferencing a pointer was AREF. C structures were also implemented 
> this way. Lisp Machines didn't have "unsafe" mode (although there were 
> low-level system primitives that allow direct memory access, since Lisp 
> was used to implement the OS), so the bounds checks in arrays couldn't 
> be bypassed.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#32798

On Thu, 25 Apr 2019 19:22:30 +0200
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote:
> Barry Margolin <barmar@alum.mit.edu> writes:
> > C was created for writing an operating system. Efficiency is extremely 
> > important, so adding bounds checks to every memory access would impose 
> > an unacceptable performance penalty.
> 
> On the other hand, ensuring that the OS doesn't crash, or doesn't leak
> security holes WAS NOT important, since UNIx was essentially a
> single-user operating system on a small mini-computer.

It is always important that the operating system doesn't crash. But if it
crashes it's only inconvenient when it happens whereas if it's too slow ,
it's inconvenient *all* the time.

> Nowadays, unix
> runs computers mostly for single-user computers (phones, tablets,
> workstations), and very rarely for multiple users on big-iron.

Citation needed. In particular I note that a workstation in a business
or academic environment will likely have multiple users ; in general only
one user will be sitting in front of the computer but other users may
be remotely logged in or run background processes. And what about a web
server ? Does it count as <single user> or <multiple users> ?

> > C's data model also makes it hard to implement these checks
> > efficiently.
> 
> Who cares, when we have pipelined Intel processors?

If by "who cares" you mean that it's pointless to worry about safety on
the language level when running code on an modern Intel processor since
it has built-in vulnerabilities {en.wikipedia.org/wiki/Intel_Management_Engine} ,
I agree completely.

-- 
Hope that no one on a film set will ever again ask me where to get a ladder. (The answer
is the Grip Department. The answer is always the Grip Department).
  http://www.svnfilm.com/resources/general-content/278-the-seven-arts-of-working-in-film-a-necessary-guide-to-on-set-protocol.html

[toc] | [prev] | [next] | [standalone]

#32802

In article <XQQSTZGRWWJ6MSCW@bongo-ra.co>,
 Spiros Bousbouras <spibou@gmail.com> wrote:

> On Thu, 25 Apr 2019 19:22:30 +0200
> "Pascal J. Bourguignon" <pjb@informatimago.com> wrote:
> > Barry Margolin <barmar@alum.mit.edu> writes:
> > > C's data model also makes it hard to implement these checks
> > > efficiently.
> > 
> > Who cares, when we have pipelined Intel processors?
> 
> If by "who cares" you mean that it's pointless to worry about safety on
> the language level when running code on an modern Intel processor since
> it has built-in vulnerabilities 
> {en.wikipedia.org/wiki/Intel_Management_Engine} ,
> I agree completely.

I think he was arguing the opposite: don't worry about performance of 
safety checks, because pipelining will mitigate it.

That's essentially how Lisp Machines dealt with it. When it executed an 
operation like PLUS, it would perform the following operations in 
parallel (this was done in microcode):

pass the operands to the FIXNUM adder
pass the operands to the FLONUM adder
check the types of the operands

If the types were both FIXNUM or FLONUM, it arranges for the result of 
the appropriate adder to be returned. If not, those results are ignored 
and it calls a generic arithmetic subroutine (or signals an error if 
either of the operands is not a number).

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#32942

On Thursday, April 25, 2019 at 7:22:34 PM UTC+2, informatimago wrote:
> ...
> Nowadays, unix
> runs computers mostly for single-user computers (phones, tablets,
> workstations), and very rarely for multiple users on big-iron.
> ...
> __Pascal J. Bourguignon__
> http://www.informatimago.com


AH, ahem, uh, (cough, cough)...  WHAT?!!!  I agree with all your overall discussion on this topic, but to take a slightly off-topic focus on the bit quoted above, "Are you sure that actually turns out to be the case??"

I think counting hardware instances, with smartphones adding with laptops and desktops and all, it probably does weigh more heavily on the "single user computers" side.  But what about Google?  Amazon?  IBM?  Even Microsoft?  These huge data center services, there's lots of machines there running Linux (I assume that counts as "Unix") and serving many, many users on each hardware frame.  Technologies like Docker are pulling users back onto a single Unix instance from VM technologies in these places.  Even in VM environments, each VM running Unix is serving so many users.

We can get into semantics of the concept of "user" versus "service request context", but, well, my point is that the idea of a multi-user Unix box is hardly "rare" these days!  (Even if the single user instances are even more abundant.)

(I don't want to contradict.. if you have a different interpretation, well OK, just wanted to add my point of view.)

[toc] | [prev] | [next] | [standalone]

#32945

On 2019-05-23, a.daniel.eliason@gmail.com <a.daniel.eliason@gmail.com> wrote:
> On Thursday, April 25, 2019 at 7:22:34 PM UTC+2, informatimago wrote:
>> ...
>> Nowadays, unix
>> runs computers mostly for single-user computers (phones, tablets,
>> workstations), and very rarely for multiple users on big-iron.
>> ...
>> __Pascal J. Bourguignon__
>> http://www.informatimago.com
>
>
> AH, ahem, uh, (cough, cough)...  WHAT?!!!  I agree with all your overall discussion on this topic, but to take a slightly off-topic focus on the bit quoted above, "Are you sure that actually turns out to be the case??"
>
> I think counting hardware instances, with smartphones adding with
> laptops and desktops and all, it probably does weigh more heavily on
> the "single user computers" side.  But what about Google?  Amazon?
> IBM?  Even Microsoft?  These huge data center services, there's lots
> of machines there running Linux (I assume that counts as "Unix") and
> serving many, many users on each hardware frame.

Firstly, those servers use virtualization. There are multiple customers,
but they have their own OS instances.

The multi-user services run on those instances are not actually multiple
logged-in Unix users. They are just sessions in some server application.
In some kinds of server applications, there isn't necessarily even a
session state; the session state is in the client browser cookie.

A webserver written in 100 lines of C running on Windows 95 can serve
multiple browsers. That doesn't make it a multi-user OS.

[toc] | [prev] | [next] | [standalone]

#32997

> Firstly, those servers use virtualization. There are multiple customers,
> but they have their own OS instances.
> The multi-user services run on those instances are not actually multiple
> logged-in Unix users. They are just sessions in some server application.
> In some kinds of server applications, there isn't necessarily even a
> session state; the session state is in the client browser cookie.

This goes to what we define as "user".  An Android phone uses many
different "uid"s even though there's a single human "controlling" it.
And on the datacenter side, a webserver serving millions of "users" may
use a single uid.


        Stefan

[toc] | [prev] | [next] | [standalone]

#32948

a.daniel.eliason@gmail.com writes:

> On Thursday, April 25, 2019 at 7:22:34 PM UTC+2, informatimago wrote:
>> ...
>> Nowadays, unix
>> runs computers mostly for single-user computers (phones, tablets,
>> workstations), and very rarely for multiple users on big-iron.
>> ...
>> __Pascal J. Bourguignon__
>> http://www.informatimago.com
>
>
> AH, ahem, uh, (cough, cough)...  WHAT?!!!  I agree with all your
> overall discussion on this topic, but to take a slightly off-topic
> focus on the bit quoted above, "Are you sure that actually turns out
> to be the case??"
>
> I think counting hardware instances, with smartphones adding with
> laptops and desktops and all, it probably does weigh more heavily on
> the "single user computers" side.  But what about Google?  Amazon?
> IBM?  Even Microsoft?  These huge data center services, there's lots
> of machines there running Linux (I assume that counts as "Unix") and
> serving many, many users on each hardware frame.  Technologies like
> Docker are pulling users back onto a single Unix instance from VM
> technologies in these places.  Even in VM environments, each VM
> running Unix is serving so many users.
>
> We can get into semantics of the concept of "user" versus "service
> request context", but, well, my point is that the idea of a multi-user
> Unix box is hardly "rare" these days!  (Even if the single user
> instances are even more abundant.)
>
> (I don't want to contradict.. if you have a different interpretation,
> well OK, just wanted to add my point of view.)

Certainly a better metric would be in order. But in anycase, by
definition there will be fewer multi-user computers than single-user
computers.

The business value of companies like Google is in reducing the number of
computers they need to use to serve the 7 billion potential users.

The business value of companies like Apple or Samsung is to increase the
number of hand-held computers the sell to the 7 billion potential users.

Apple will never make a iUberPhone!  "Press a button, and some random
iPhone will be brought to your position in less than five minutes so you
make your call or send you tweet!"  Anybody?

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#32950

On Thursday, May 23, 2019 at 10:30:28 AM UTC-7, informatimago wrote:
> 
> Certainly a better metric would be in order. But in anycase, by
> definition there will be fewer multi-user computers than single-user
> computers.

I might quibble that this is not necessarily axiomatic.
Certainly in the early history of computing there were more multi-user
computers. But enough of pedantry. Especially if you count smart phones
as computers.

> The business value of companies like Google is in reducing the number of
> computers they need to use to serve the 7 billion potential users.
> 
> The business value of companies like Apple or Samsung is to increase the
> number of hand-held computers the sell to the 7 billion potential users.
> 
> Apple will never make a iUberPhone!  "Press a button, and some random
> iPhone will be brought to your position in less than five minutes so you
> make your call or send you tweet!"  Anybody?

This sounds like a great premise for an April 1st post. Especially since
one could work autonomous drone delivery of the phones into it. Maybe
I'll try writing that next year...

[toc] | [prev] | [next] | [standalone]

#32951

taruss@google.com writes:
> This sounds like a great premise for an April 1st post. Especially since
> one could work autonomous drone delivery of the phones into it. Maybe
> I'll try writing that next year...

Someone wrote a program a while back, not even on April 1, that would
simultaneously order a pizza delivered to some random location in your
city, and call an Uber to get you to that location to receive the pizza.

I don't know if there's a word for something funny and horrible at the
same time, but that would qualify.

[toc] | [prev] | [next] | [standalone]

#32952

Paul Rubin <no.email@nospam.invalid> writes:

> taruss@google.com writes:
>> This sounds like a great premise for an April 1st post. Especially since
>> one could work autonomous drone delivery of the phones into it. Maybe
>> I'll try writing that next year...
>
> Someone wrote a program a while back, not even on April 1, that would
> simultaneously order a pizza delivered to some random location in your
> city, and call an Uber to get you to that location to receive the pizza.
>
> I don't know if there's a word for something funny and horrible at the
> same time, but that would qualify.

The truth is that I've lived in a lot of different places (not
excessively many, but still), and strangely enough, a surprising high
number of them didn't have an address that was easy to find for people
not knowing where they were.  And mind you, all those places had
definite specific addresses, I'm not speaking of places in a desert, but
civilized streets.

Therefore, I wouldn't find useless such a service, where you would meet
the delivery man at a place at an address more easily found…  At least
until NAC codes are generalized http://www.nacgeo.com/nacsite/

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#32953 — [OT] was: Buffer Overflow in LISP

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Paul Rubin <no.email@nospam.invalid> writes:
>
>> taruss@google.com writes:
>>> This sounds like a great premise for an April 1st post. Especially since
>>> one could work autonomous drone delivery of the phones into it. Maybe
>>> I'll try writing that next year...
>>
>> Someone wrote a program a while back, not even on April 1, that would
>> simultaneously order a pizza delivered to some random location in your
>> city, and call an Uber to get you to that location to receive the pizza.
>>
>> I don't know if there's a word for something funny and horrible at the
>> same time, but that would qualify.
>
> The truth is that I've lived in a lot of different places (not
> excessively many, but still), and strangely enough, a surprising high
> number of them didn't have an address that was easy to find for people
> not knowing where they were.  And mind you, all those places had
> definite specific addresses, I'm not speaking of places in a desert, but
> civilized streets.
>
> Therefore, I wouldn't find useless such a service, where you would meet
> the delivery man at a place at an address more easily found…  At least
> until NAC codes are generalized http://www.nacgeo.com/nacsite/

There's always "what three words": https://what3words.com/

Not yet sure if it's just a neat idea or a useful one.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#32955 — Re: [OT] was: Buffer Overflow in LISP

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>> Paul Rubin <no.email@nospam.invalid> writes:
>>
>>> taruss@google.com writes:
>>>> This sounds like a great premise for an April 1st post. Especially since
>>>> one could work autonomous drone delivery of the phones into it. Maybe
>>>> I'll try writing that next year...
>>>
>>> Someone wrote a program a while back, not even on April 1, that would
>>> simultaneously order a pizza delivered to some random location in your
>>> city, and call an Uber to get you to that location to receive the pizza.
>>>
>>> I don't know if there's a word for something funny and horrible at the
>>> same time, but that would qualify.
>>
>> The truth is that I've lived in a lot of different places (not
>> excessively many, but still), and strangely enough, a surprising high
>> number of them didn't have an address that was easy to find for people
>> not knowing where they were.  And mind you, all those places had
>> definite specific addresses, I'm not speaking of places in a desert, but
>> civilized streets.
>>
>> Therefore, I wouldn't find useless such a service, where you would meet
>> the delivery man at a place at an address more easily found…  At least
>> until NAC codes are generalized http://www.nacgeo.com/nacsite/
>
> There's always "what three words": https://what3words.com/
>
> Not yet sure if it's just a neat idea or a useful one.

Depending on what word you pluralize you get different positions in
different continents.  I deem that a defect, it shouldn't be that
sensitive to the spelling.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#32956 — Re: [OT] was: Buffer Overflow in LISP

On 2019-05-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> There's always "what three words": https://what3words.com/
>
> Not yet sure if it's just a neat idea or a useful one.

Aptly criticized by:

https://shkspr.mobi/blog/2019/03/why-bother-with-what-three-words/

(Submitted to HackerNews back in March).

[toc] | [prev] | [next] | [standalone]

#32957 — Re: [OT] was: Buffer Overflow in LISP

Kaz Kylheku <847-115-0292@kylheku.com> writes:

> On 2019-05-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> There's always "what three words": https://what3words.com/
>>
>> Not yet sure if it's just a neat idea or a useful one.
>
> Aptly criticized by:
>
> https://shkspr.mobi/blog/2019/03/why-bother-with-what-three-words/

That's a  good summary, thanks.   Interestingly (at  least to me)  I had
assumed it was an open source project simply because I could not see how
anyone would want to bother if it were proprietary!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#32989

Pascal, You might like https://what3words.com for naming and finding
locations.

-Jason

[toc] | [prev] | [next] | [standalone]

#32991

Jason Cornez <jcornez@ravenpack.com> writes:

> Pascal, You might like https://what3words.com for naming and finding
> locations.

Thanks. This has been mentionned, but it looks like there are several
problems with it, one of them being that it's a proprietary dictionary.

Another thing is that user may try to change their location (or location
indication) to get a better choice of words.  So the final precision will
often be less than with NAC.  http://www.nacgeo.com

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.lisp

csiph-web